1            Introduction

1.1          Background

Today’s software intensive systems are typically developed utilizing traditional methods and processes that do not adequately provide for the complexity of developing and integrating systems built with separately developed software components. The increase in system complexity, increased testing, security, and reliability requirements are driving the need for increased specificity of information that is exchanged between these components.

This increase in complexity of software-intensive systems causes designers to architect systems as reusable software components that are then “glued” together to achieve an overall systems implementation. This approach aids in software reuse, but can also lead to an increase in software integration costs and mismatch between components designed by different teams.

A new approach is required in order to advance software integration methods to enable disparate development, reduce integration problems, and aid in software reuse for the purpose of increasing system reliability, reduced schedule, and overall reduced cost of development and integration.

1.2          FACE Data Architecture Approach

The Future Airborne Capability Environment (FACE) Data Architecture was designed to address the need to advance software-intensive system integration. The approach employed is to develop a highly specified data modelling language, Configuration Control Board (CCB) managed Shared Data Model (SDM), Conformance Policy, and Conformance Test Suite (CTS). Together these elements constitute the FACE Data Architecture.

Ultimately, the FACE Data Architecture key objectives are to reduce software integration costs and time-to-field complex and reliable capabilities.        

1.4 How to Use this Guide

This guide is written so the reader can get a quick start on understanding and creating data models. Chapter 2 should be read prior to reading any other sections. Once the basic structure and goals of the FACE Data Architecture are understood, the reader can then pick and choose which sections to read.

Appendix A can be referenced to aid in the understanding of specific terms used throughout this document.

For consistency, the examples build primarily from one example data model, except when a different example data model more clearly presents a concept. Section 2.3.1 describes the Graphical Notation used for all the example models in this document.

The following typographic conventions are used throughout this document:

•         Metamodel Elements

•         Important topic

•         “Model Element”

Best practices are identified as follows:

Best Practice:

These are provided to aid the reader in useful and sometimes preferred modelling techniques but should not be construed as the only approach to modelling that type of element.

Pitfalls are identified as follows:

Pitfall:

These are provided to assist the reader by identifying an area that may cause confusion.

Notes are identified as follows:

                   Note:      These are intended to provide additional details about the topic being discussed.

 

2            Data Architecture Overview

The purpose of this chapter is to introduce the reader to resources for FACE data modelling before progressing into a deeper study of the building blocks of the FACE Data Architecture. This chapter describes the philosophies supporting the need for data modelling (Section 2.1), an overview of the Data Architecture concepts (Section 2.2), and an introduction to the data model notation used throughout the document with references to examples (Section 2.3.1).

2.1         Why Data Modelling?

The obvious answer as to why data modelling is employed in the FACE Technical Standard is to achieve the goal of developing software-intensive systems that have a high level of complexity. It has been noted that the complexity of systems is growing at an alarming rate and will achieve a 10x complexity increase in the next 20 years. Our current development architectures are proving inadequate to achieve this increased complexity and achieve the reliability, safety, and security requirements being placed on these systems. A new approach is required in order to advance software integration methods to enable disparate development, reduce integration problems, and aid in software reuse for the purpose of increasing system reliability, reduced schedule, and overall reduced cost of development and integration.

The FACE Data Architecture is designed specifically to achieve its key objectives by developing an architecture supporting engineering design specifications for data and interfaces such that there are no ambiguities in these designs for the purpose of component integration. The specificity necessary for data type, units, precision, frame of reference, and the semantic description of Entities and Associations are captured in a machine-readable format. By providing for unambiguous semantic and measurement system descriptions of data elements, developers can specify information with sufficient specificity to increase interoperability of FACE Units of Portability (UoPs).

Another, yet very practical reason for data modelling is that the FACE Reference Architecture requires a FACE Data Architecture-conformant data model to provide a standard method for defining the data format and meaning for information sharing between software components. Data modelling is required to enable information sharing/interoperability between components (e.g., FACE UoPs).

The benefits of utilizing the FACE Data Architecture toward improving interoperability are:

•         Unambiguous specification of data elements

•         Unambiguous specification of information exchanged between UoPs

•         Reusability of data model elements through the SDM, Domain-Specific Data Models

(DSDMs), and UoP Supplied Models (USMs)

•         Reduced data model development cost and schedule through reuse

•         Reduced software component development cost and schedule through reuse

•         Reduced integration cost and schedule through unambiguous specification of information exchanged between UoPs

The FACE Data Architecture is a key component of the FACE Technical Standard and is essential to designing systems and developing interoperable UoPs. The FACE Data Architecture eases the identification of horizontal interface mismatches often found during development/integration of a system composed of software from multiple suppliers. The data modelling language enables existing components to be made conformant to the FACE Data Architecture with minimal modification to interfaces by modelling the semantics of the information exchanged through the existing interfaces.

2.2          Overview of Data Architecture Concepts

The FACE Data Architecture is made up of a data model language, a common SDM that establishes foundational elements for modelling, and a Conformance Policy with accompanying data model CTS.

The FACE Data Model Language utilizes the Meta-Object Facility™ (MOF™) metamodel language as its foundation, two grammar-based languages, and Object Constraint Language (OCL)-defined constraints to define the structure and rules for construction, interaction of model elements, and software code generation. The FACE Data Architecture consists of four primary model groupings:

1.          Data Model:

— Conceptual Data Model (CDM)

— Logical Data Model (LDM)

— Platform Data Model (PDM)

2.          UoP Model

3.          Integration Model

4.          Traceability Model

 

Figure 1: FACE Architecture Models without Traceability Model

Figure 1 shows the various constituent models that make up the FACE Data Architecture and the relationships between the models. The progression from left to right is from abstract to concrete. With each level of refinement, the degree of specificity increases moving the model closer to a complete definition of the software application solution required for generation of code.

The first of the Architectural Model elements, the Data Model, is used to define data elements with unambiguous specificity for use in the FACE Technical Standard. The Data Model is divided into three different data elements with unambiguous specificity for use by FACE UoPs or DSDMs, as defined by the FACE Technical Standard:

•         The Conceptual Data Model (CDM) provides the semantic definition of the entities and their relationships characterized by Observables

•         The Logical Data Model (LDM) adds measurement information to each characterization by defining value type, unit, measurement, and frame of reference (through the measurement system)

•         The Platform Data Model (PDM) adds physical data type information to the logical measurement characterization

The UoP Model provides the definition of a software component and its defined interfaces.

Note: As of the FACE Technical Standard, Edition 3.0 the terms UoP and UoC are interchangeable. We use the term UoP in this guidance document since the metamodel contains “UoP”-named model elements.

The Integration Model provides a mechanism to describe the Transport Services Segment (TSS) integration details between two or more UoPs.

Lastly, the Traceability Model, not shown in Figure 1, provides a mechanism to trace model elements to an external model. Select elements from an existing model declared from the Data Model or UoP Model elements are decorated with a reference to standards-based model types. Since the Traceability Model does not directly contribute to the meaning of the data, it is not shown in Figure 1.

The Shared Data Model (SDM) establishes a foundation of core data elements used as building blocks to create all other data models. Because the SDM is CCB managed, it is reliable and provides confidence in the core modelling elements and utility of reuse and potential of reduced data conversion needs.

The Conformance Policy, and supporting data model CTS, maintains the integrity of FACE Data Models for the purpose of data model reuse and integration. Since the USM and DSDM must be validated as conformant in order to be placed in the FACE UoC library, developers can expect a certain level of data integrity in these models.

Note: The Conformance Policy and tests do not perform a qualitative analysis of data model elements. Conformance only means that the elements adhere to the structure and constraints of the FACE Data Architecture.

The Domain-Specific Data Model (DSDM) is a data model designed to the FACE Data Architecture requirements. It captures domain-specific semantics and generally does not contain UoP Models.

2.2.1	Data Model Language
2.2.1.1	Data Models
2.2.1.1.1	Data Entities and Associations

The Entities, Associations, their Characteristics, and the Characteristic’s data types, at all three model levels, provide context for and give meaning to the data required or provided by a UoP. Using this information in its entirety, it is possible to not only determine if the required data of one UoP is (or is not) equal to the provided data of another UoP in terms of implementation type and size, frame of reference, and value domain; it is also possible to determine if the provided and required data shares (or does not share) the same conceptual meaning. This determination is critical to supporting interoperability and being able to successfully integrate UoPs.

For example, consider that UoP A provides and UoP B requires a WGS-84 position tuple consisting of latitude, longitude, and height, each using metric units (radians and meters), and each implemented as floating point numbers. Without context, the information exchanged, although completely and unambiguously specified, does not provide enough detail to understand whether or not each of the position parameters refers to the same real-world concept: UoP A may be providing the position of a platform executing a mission, whereas UoP B may require the position of an enemy jamming radar frequencies. Entities and Associations provide this context, unambiguously providing meaning to the data exchanged.

By specifying this information for a UoP, the System Integrator can not only determine if the data is the same or different in terms of implementation size and type, frame of reference, and units, requiring a conversion if necessary, but can also determine if there is semantic mismatch and address it accordingly.

The CDM captures the semantic meaning of the data elements. It accomplishes this by defining Observables that are used to define the Characteristics of each Entity. Entities are related to each other via an Association. Like an Entity, an Association is described unambiguously through Characteristic Compositions and Participant entities in the Association. Lastly, the CDM allows definition of conceptual data Views (Query) based on those entities and Characteristic Compositions. Data Views (Query) are described below.

The LDM provides a mechanism to extend each conceptual element with information that supports particular logical processing requirements: Units, Measurement and Coordinate Systems, value Domains (e.g., Real, Natural Number), and Constraints. Each conceptual element can have many representations at the logical level based on the selection of each of these additional elements of information. Also, conversion relationships between logical elements may be specified in the LDM. This provides a mechanism for sharing data between components that have different algorithms and therefore different data representations. For example, the same conceptual element representing the concept of altitude could be represented as an integer number of meters above ground level and as a real number of feet above mean sea level. The fact that these two representations are linked to the same concept informs users that direct conversions between them are realizable. The existence of conversions between the Units, Measurement and Coordinate Systems, value Domains (e.g., Real, Natural Number), and Constraints defines the method of performing those conversions.

The PDM takes the LDM a step further by allowing each logical element to be further described with the specifics of the software implementation. The PDM defines the specific data type such as float or double used to represent the value type allowing the logical type to be represented for the specific processing need of a UoP.

                   Note:            The data types are defined in the FACE Technical Standard with OMG IDL™;

however, an implementation will likely generate source code for the UoP’s programming language. In other words, IDL is not required to be generated, but is used for the definition of how code must be generated as defined by the FACE Technical Standard.

2.2.1.1.2        Data Views

Another concept to introduce is that of a View, supported by the FACE Data Architecture and covered in further detail in the Application Perspective sections in later chapters. A view is an abstract element in the metamodel whose function is to select a subset of a data model’s entities and associations that are of interest. It assembles specific Characteristics of one or more Entities and preserves the context of each Characteristic. The primary utility of views is to assemble information that is necessary and useful for a particular purpose without imposing unique specifications and requirements of that purpose throughout the entire system, or on other systems.

Views created at the conceptual, logical, or platform level of the model have the same level of abstraction as other data model elements. They can also have relationships from a view in the CDM to one or more views in the LDM; that is, a view in the LDM can realize a view in the CDM. Similarly, a view in the LDM may be realized by one or more views in the PDM; that is, a view in the PDM may realize a view in the LDM. It is also acceptable to have logical Views that are not realizations of conceptual Views and platform Views that are not realizations of logical Views. Because it is possible to have both conditions, it is necessary to decide when a logical View is independent, and when it is a realization of a conceptual View.

Views in the CDM are collections of Characteristics. They are a specification of a View that is to be realized by several corresponding logical Views. It is desirable to create a conceptual View when there are several logical Views that have identical conceptual content, but different representations of the concepts. The ability to indicate that each of the different logical Views realizes the same conceptual View clarifies the role that each logical View plays within the system and reduces the effort needed to map between the different logical Views. It is also useful to create conceptual Views to represent the conceptual interfaces of components or services. The most common use of such a view is to describe the information exchanges of an AbstractUoP.

Note: Conceptual and logical Views are not required for conformance validation. However, if they are modeled and subsequent layers of the model realize the Views, then conformance validation checks will be applied to the Views to ensure consistency.

2.2.1.1.3        Data Model Levels

The FACE Data Architecture divides the FACE Data Model into three levels: Conceptual, Logical, and Platform Data Models. These three levels of model provide for the incremental definition of data. The levels provide a separation of concerns that supports reuse of data models. Modelling first focuses on developing domain concepts (conceptual), then elaborating (logical and platform) until the UoP interfaces have been fully specified.

Note: This division of data models aligns with both Model-Driven Architecture^® (MDA^®) conventions and the Department of Defense Architecture Framework (DoDAF) metamodel.

 

Figure 2: Metamodel Elements and their Progressions

The separation of the data model into three levels supports key interoperability requirements of the FACE Technical Standard and enables efficient transformation of existing components into FACE UoPs.

Each of the three levels of data models includes Entities, Associations, and View model elements. The Entity and Association elements provide a semantic description of the data elements through Characteristics and Associations between the Entities, whereas the Views provide a description of the data set that can be sent or received by a UoP. In the sections above, the Conceptual, Logical, and Platform Data Models were introduced. They are defined in more detail in the following sections.

2.2.1.1.4        Conceptual Data Model (CDM)

The CDM contains CDM elements such as Domain, BasisEntity, Observables, Entity, Association, and View (Query). These elements allow modelers to define application Domain concepts, their Characteristics, and the relationships between them. Observables are used to type the Characteristics of Entities and Associations. The CDM also supports a method to define BasisEntities that can be used to specify Domain concepts.

The value of the CDM is the level of abstraction at which it is represented and that it provides the definition of each Entity/Association. As the most abstract of the three data models, it provides the most reuse. One way to think of the CDM is that of ontology. It is very similar in that the model of each Entity defines the Entity by specifying the Characteristics of the Entity.

2.2.1.1.5        Logical Data Model (LDM)

The LDM contains LDM elements such as: Measurement System, Measurement,

MeasurementAttribute, ValueType, Enumeration, Unit, Constraint, Conversion, Entity, Association, and View (Query). The main LDM elements are explicitly modeled as realizations of their CDM element counterparts. The LDM further refines the conceptual Observables, Entities, Associations, and Views defined in the CDM.

Refinement from the conceptual to logical level includes:

•         Refining Observables to Measurements by specifying value type (e.g., real, integer) and unit (e.g., meter, feet), and frame of reference modeled by a Measurement System (e.g., WGS-84, ECEF)

•         Selecting which Conceptual Entity and Association Characteristic Compositions and

Participants to include in the logical representation of the Entity/Association

•         Selecting which Measurements and Entities are used to type Entity/Association Characteristic Compositions

•         Deciding if multiple refinements of Characteristics are required when more than one logical design is warranted for an Entity/Association (see Section 4.5.3.3.1)

•         Refining Views by adding more details to the selection criteria

The value of the LDM is that it becomes more concrete and less abstract, which is of particular value to stakeholders who rely on detail, such as System Integrators and software implementers. At the logical level the model does lose some of its ability to be reused due to the Characteristics chosen for the Entity/Association and the Measurements chosen to represent those Characteristics.

2.2.1.1.6        Platform Data Model (PDM)

The PDM contains PDM elements such as: IDLPrimitive, IDLStruct, Precision; Entity, Association, View (Template and Query). Most PDM elements are explicitly modeled as realizations of their LDM element counterparts. The PDM further refines the logical Measurements, Entities, and Associations defined in the LDM.

Refinement from the logical to platform level includes:

•         Refining logical Measurement, MeasurementAxis, and ValueTypeUnit elements to IDLTypes (IDLPrimitives and IDLStructs) to define their structure and physical type

•         Selecting which Logical Entity/Association Characteristic Compositions and Participants to include in the platform representation of the Entity/Association

•         Selecting which IDLPrimitives, IDLStructs, and Entities are used to type

Entity/Association Characteristic Compositions

•         Deciding if multiple refinements of Characteristics are required when more than one platform design choice is warranted for an Entity/Association (see Section 4.5.3.3.1)

•         Refining Logical Querys into Platform Queries and Templates to define the structure of the information exchanged

IDLPrimitives supported by the PDM correspond directly to Interface Definition Language

(IDL) data types and include: IDLSequence, IDLArray, Boolean, Octet, Char, String,

BoundedString, CharArray, Enumeration, [U]Short, [U]Long, [U]LongLong, Double, LongDouble, Float, and Fixed. The FACE Technical Standard provides PDM to IDL bindings and mappings to each supported programming language.

The value of the PDM is that with the IDL types and query/template definitions, the model is starting to approach working code. At the platform level, the ability to reuse the model across multiple Domains is reduced significantly. This is expected as it is tied so closely to the implementation.

2.2.1.2         UoP Model

The UoP Model contains UoP Model elements such as AbstractUoP, UnitOfPortability,

ComponentFramework, PubSubConnection, ClientServerConnection, and Thread. A UoP Model provides the means to formally specify the interfaces of a UoP in terms of data and communication Characteristics. These interfaces, modeled using the Connection model elements, reference platform Views that specify the data that passes through the interface. Connection model elements are representations of “logical” (in the traditional use of the word) connections and do not necessarily correspond to the actual communication channels for exchanging data.

The AbstractUoP element supports a platform-independent specification of the UoP by using AbstractConnections that reference either logical or conceptual Views.

The value of the UoP Model is that it provides a description of the FACE UoP in terms of its interfaces, and communication and implementation details that can be used during integration efforts. In the Integration Model, discussed below, a UnitOfPortability can be realized as a UoPInstance.

2.2.1.3         Integration Model

The Integration Model contains elements such as UoPInstance, TransportChannel,

                   IntegrationContext;         TransportNode         (ViewSource,         ViewSink,         ViewFilter,

ViewTransformation, ViewAggregation, ViewTransporter). An Integration Model provides the means to model the exchange of information between UoPInstances. An Integration Model captures data exchanges, view transformations, and integration of UoPs for documentation of integration efforts. An Integration Model relies on the UoP Models for expressing interconnectivity. The focus is on documenting UoP data exchange details. Refinement from UoP Model to Integration Model includes:

•         Refinement of UnitOfPortability elements as UoPInstance elements

•         Selection of Connection elements for UoPEndPoint elements

The value of the Integration Model is that it provides a concrete view for the System Integrator to work through the integration of the FACE conformant component with other FACE conformant components. The Integration Model provides transparency into the information exchange and view transformations. This transparency also permits the System Integrator to create integration test artifacts.

                   Note:      The Integration Model is not used for conformance and is therefore optional.

2.2.2          FACE Shared Data Model

The FACE SDM provides the basis set of elements from which all USMs and DSDMs are built. The SDM is a repository of data elements that may be leveraged or extended by Software Suppliers developing UoPs. It is a set of managed elements that provides a common set of building blocks for all data models. It defines a set of Observables at the conceptual level. It also defines the Units, Measurement and Coordinate Systems, and related information needed to construct Measurements which are a logical representation of the conceptual Observable.

The SDM and its content are governed by the FACE Shared Data Model Governance Plan and managed by the FACE SDM CCB. In addition, a FACE subcommittee meets weekly to address requested changes to the SDM. The FACE Shared Data Model Governance Plan details the governed elements, SDM conformance requirements, and the process for maintaining and updating the SDM. The Governance Plan should be consulted for a complete list of managed elements and the process for SDM modification. When a new SDM CCB managed element is required for a DSDM or USM, a Change Request (CR) is submitted through the online FACE Problem Report/Change Request (PR/CR) tool. Requests are anonymous and will be worked into the subcommittee’s weekly agenda as soon as reasonably possible. Requests should be as specific as possible and provide the subcommittee with enough information and context for making an informed decision. The subcommittee may respond to the submitters for additional information. If not addressed in three weeks by the submitter, the request will typically be considered abandoned and will be subsequently rejected.

The value of the SDM is that it establishes a common starting point or common semantic model from which all other models are built. The SDM focuses on engineering primitives that reduce ambiguity normally associated with textual representation. This allows the modeler to build on top of the more primitive elements to create a model for their domain or application.

                   Note:           The SDM is coupled to a specific major edition of the FACE Technical Standard.

Therefore, an SDM 3.0.x must be used for conformance to the FACE Technical Standard, Edition 3.0.x and an SDM 2.1.x must be used for conformance to the FACE Technical Standard, Edition 2.1.

2.2.2.1         Shared Data Model Organization

Packages in the SDM create a hierarchy of data model elements. Packages within the SDM are informational only. For example, the SDM groups Observables under one top-level package inside the CDM. Observables are further grouped into packages identified by common classifications. When an Observable is added it should be placed into an existing package if a reasonable one can be found. If an appropriate package cannot be found, then a new package can be created to hold the Observable.

The following examples of the SDM are extracted from the SDM 3.0. The SDM 3.0 release may reorganize elements.

 

Figure 3: Sample FACE SDM 3.0 Organization

Figure 3 shows the top-level structure of the SDM. The SDM focuses on the Conceptual and Logical data elements and does not currently include Platform or UoP elements. These are described below.

2.2.2.1.1        Conceptual Data Model Organization

The Conceptual SDM consists mainly of Observables. The Observables are categorized by the concepts they portray. In many cases the Observables are aligned with concepts relating to the International System of Units (SI units). Figure 4 shows a snapshot of the Conceptual SDM.

 

Figure 4: SDM Version 3.0.3 Sample Conceptual Data Model Organization

2.2.2.1.2        Logical Data Model Organization

The Logical SDM primarily consists of model elements that support the means to measure the conceptual Observables. The logical elements are categorized by metamodel type and then by the concepts they portray. These logical elements are divided into their metamodel type which relates to each elements role in the holistic measurement: CoordinateSystems, LogicalValueTypes, Units, ValueTypeUnits, Landmarks, ReferencePoints, Constraints, MeasurementSystems, Measurements, and Enumerations. These types are defined by the FACE Metamodel in the FACE Technical Standard. The following diagrams provide a sample reference of the SDM logical structure. Figure 5 shows the top-level logical structure.

 

Figure 5: SDM Version 3.0.3 Sample Logical Data Model Organization

Figure 6 shows the expanded “CoordinateSystems” package from Figure 5. All of the elements that make up the “Cartesian” “Coordinate System” are contained in the Cartesian package.

 

Figure 6: SDM Version 3.0.3 Sample Logical Data Model – Coordinate Systems

 

Figure 7: SDM Version 3.0.3 Sample Logical Data Model – Example Measurement Systems

Figure 7 shows an example of a measurement system expansion. These figures are a small example of the structure of the SDM Measurement Systems organization.

                   Note:      Each package/folder is a data model as defined by the metamodel.

2.3         Introduction to the Data Modelling Example

This section defines the style and notation used throughout this document to foster a common interpretation of the concepts and provide the readers with a credible example model from which to begin. The examples used in this document are sourced from a supplemental working model based on a Relevant Operating Picture (ROP) domain content. Unless otherwise stated all example material is a direct reference into the sourced model.

2.3.1          Style Guide for the Examples

The FACE Data Model does not define a graphical notation for representing FACE Data Model elements. However, it is useful to view models graphically, so this guidance uses the following graphical notation for these examples.

The notation is divided into the various model types: Conceptual, Logical, Platform, UoP, and Integration Models. For the Microsoft^® PowerPoint^® graphical format for the example, see Chapter 8 for further information.

•         The color of the element matches the model in which it is contained

The colors are those used in the FACE Technical Standard §3.9.1 and in Figure 1 above.

•         The format of each element is the element type surrounded by angle brackets: << Type >>

•         The Name assigned to the element chosen by the user

•         A list of sub-elements; for example, Rolename : Type Connectors are depicted with a line that varies in:

•         Line style

•         Optional decoration on each end of the line

•         The type surrounded by angle brackets: << Type >>

•         Multiplicity specifies the number of elements and is shown as (min … max) where * represents infinity, and a single digit represents a matching minimum and maximum value

Figure 8 shows a simple CDM describing a dog ownership relationship between a Person and a Dog.

 

Figure 8: Example Conceptual Data Model

The following sections show the graphical notation elements divided into the different data model categories: Conceptual, Logical, Platform, UoP, and Integration.

2.3.1.1         Conceptual Data Model

 

Figure 9: Conceptual Data Model Graphical Notation

2.3.1.2         Logical Data Model

 

Figure 10: Logical Data Model Graphical Notation

2.3.1.3         Platform Data Model

 

Figure 11: Platform Data Model Graphical Notation

2.3.1.4         UoP Model

 

Figure 12: UoP Model Graphical Notation

2.3.1.5         Integration Model

 

Figure 13: Integration Model Graphical Notation

2.3.2          Where to Find the Examples

The examples in the following sections of this document are sources from a supplemental working model based on ROP domain content. The example XMI^® (.face) file used in this document is located in Appendix B.

3            Data Architecture Specification

A Data Architecture specification is a series of models that are effectively contained under a high-level Architecture Model which is defined as the top-level element of the metamodel. The overall structure of the Data Architecture separates the context and detail into smaller models as a means to simplify the development of each model and increase reusability of elements at each modelling level.

Figure 14 is a roles and relationships matrix which provides a notional picture of each submodel’s contribution to the specification. The rows in the table are color coded to match the color scheme used in the Data Architecture graphical notation described in Section 2.3. The Architecture Model is the overarching model for all sub-models, as shown by the leftmost column of Figure 14. Each column of the table highlights the principal application of detail separation in the architecture and each subsequent row in the table highlights the principal application of context separation.

		Data Architecture
	Detail:	Context:	Observation Perspective	Entity-Association Perspective	Application Perspective
	Data Model	Conceptual Data Model (CDM)	Observables	Semantics	Query View
		Logical Data Model (LDM)	Measurements Measurement Systems	Refines with Measurements and Constraints	Refines Query View using LDM Entities
		Platform Data Model (PDM)	IDL Data Types	Refines with Types, Multiplicities, and Constraints	Refines the View refining the Query using PDM Entities Defines IDL style Template for DM Type code generation
	UoP Model				PCS, PSSS, Connections (link to Templates)
	Integration Model				TSS data transformation and linkage
	Traceability Model		External Model Traceability	External Model Traceability	External Model Traceability

Figure 14: Data Architecture Perspectives and Models

The perspectives, represented as columns in Figure 14, are described as:

•         Observation Perspective: describes the leaf data elements used to type Entity and Association Characteristics

•         Entity-Association Perspective: describes data elements that define the meaning and context of application concepts and their relationships

•         Application Perspective: describes the application (or use) of data elements by software components supporting component interface integration

The concept of perspectives, although not a formal part of the data model specification, is used to focus on similar cross-cutting concepts across the different model levels.

This chapter introduces aspects of the Data Architecture shown in Figure 14.

Chapter 4 and Chapter 5 describe:

•         The hierarchical nature of the architecture

•         The separation of context described by the perspectives

•         The separation of detail for the data model described by the nested models: Conceptual,

Logical, and Platform, as referenced in Figure 14

•         Model navigation and organizational concepts

Upon completion of these chapters, the reader should have a complete understanding of all the contributing parts of the Data Architecture and be ready to apply those concepts to the example model walk-through in Chapter 6.

4            Overview of Key Architectural Features

The Architecture Model is comprised of the four models: Data Model, UoP Model, Integration Model, and Traceability Model.

4.1          Data Model

The Data Model is the top model that focuses on decomposition of the information exchanged by a UoP. The intent is to develop a data-centric picture of the operational context for a UoP, separating the context and the detail into the appropriate sub-model’s ease of maintainability, facilitating reusability and interoperability. The Data Model sub-models are covered in further detail later in this document.

4.1.1          Conformance

The Data Model is required to be evaluated for conformance. The CTS performs the evaluation on a USM and the versioned SDM upon which it is dependent.

Note: The conformance evaluation is performed on a USM in its entirety. This is an important distinction because the metamodel allows a USM to include multiple UoPs or broader scoped domain elements that are not referenced by the UoP under test. Should elements not directly contributing to a UoP under evaluation be in error, the USM as a whole will fail conformance.

4.2          UoP Model

The UoP Model is the prescriptive model that ties the Data Model aspects to the FACE Technical Standard. This model captures metadata with respect to characterization of the UoP in three functional areas: UoP requirements, defined interfaces, and Transport Service (TS) integration.

4.2.1          UoP Requirements

The FACE Technical Standard defines requirements for a UoP that must be met to satisfy conformance. These requirements identify Characteristics of the UoP with respect to care and feeding necessary to function within the architecture of a FACE system and readily identified by the FACE Conformance Verification Matrix (CVM). These UoP Characteristics provide details regarding the operating system interfaces, memory footprint, lifecycle requirements, communication channels, certification levels, and technical characteristics that enable informed decisions for performance and capabilities.

4.2.2          Transport Service Integration

The FACE Technical Standard defines that UoPs communicate to each other through a

Transport Service (TS) and that a USM defines the information exchanged by the UoP. This is

true for both the Platform-Specific Services Segment (PSSS) UoPs and the Portable Component Segment (PCS) UoPs. In addition, UoPs can identify lifecycle management connections defined by the USM.

4.2.3          AbstractUoP

An AbstractUoP is defined in the FACE Technical Standard as follows: “An AbstractUoP is used to capture the specification of a UoP.” The AbstractUoP exists to allow the specification and procurement of a FACE UoP while still allowing innovation to occur in the design and implementation of the actual UoP. An AbstractUoP uses either CDM Views or LDM Views to capture the specification data to be exchanged by a UnitOfPortability implementing the specified AbstractUoP.

4.2.4          Conformance

While the AbstractUoP is not used for the FACE Conformance Program, UoPs can “realize” the AbstractUoP to identify that the UoP implements the specified AbstractUoP. This method can be useful for specification and procurement of UoPs without detailing their implementation. Whoever procures the software can evaluate the model to ensure the specification is met by the implemented software components.

If submitted, the CTS will verify the AbstractUoP for errors against the metamodel and OCL constraints. Should any of these constraints fail, the CTS results will reflect those failures and affect the conformance process. Therefore, the recommendation is to only submit the AbstractUoP as part of conformance if there are business reasons driving that decision.

4.3          Integration Model

To address integration between UoPs, the FACE Data Model Language provides elements for describing the high-level connectivity, routing, and transformations to be embodied in an instance of transport services called the Integration Model. An Integration Model consists of elements that provide the means to model the exchange of information between UoP instances. An Integration Model documents the data exchanges, view transformations, and integration of UoPs. This documentation is useful for UoP integration efforts. An Integration Model relies on UoP Model Views for expressing connection data.

The value of the Integration Model is that it provides a modelling capability for the System Integrator to work through the integration of FACE conformant components with other FACE conformant components. The integration model can be used to:

•         Provide transparency into the information exchange, view transformation, etc.

•         Enable the System Integrator to create integration test artifacts

•         Develop configuration artifacts for a TS

•         Construct TS Type-specific code for messages and data types used in an integration context

The Integration Model should contain two or more UoPInstances whose transport connections and data transformations are described through one or more IntegrationContexts.

Figure 15 shows an example of an Integration Model showing all Integration Model elements.

 

Figure 15: Integration Model Example

An Integration Model is constructed from the following primary model elements:

•         IntegrationContext: a collection of all TSNodeConnections and TransportNodes that are part of a transport; it must have at least one ViewTransporter specifying that data is transported across a TS:

— TSNodeConnection: connect UoPs through transport nodes (Views at each input and output of a transport node)

— TransportNode: a node that performs some processing The following are types of TransportNode:

— ViewSource:

— No Input Ports

— 1 Output Port – Multiple connections per Port — ViewSink:

— 1 Input Port – Multiple connections per Port

— No Output Ports — ViewAggregation:

— >1 Input Port – Multiple connections per Port — 1 Output Port – Multiple connections per Port — ViewTransformation:

— 1 Input Port – Multiple connections per Port

— 1 Output Port – Multiple connections per Port — ViewFilter:

— 1 Input Port – Multiple connections per Port — 1 Output Port – Multiple connections per Port — ViewTransporter:

— 1 Input Port – Multiple connections per Port

— 1 Output Port – Multiple connections per Port

                          UoPInstance: a realization of a UoP containing UoPInputEndpoints and

UopOutputEndpoints; it has 0 or more inputs and 0 or more outputs (one for each UoP Connection):

— UoPInputEndPoint: each endpoint is an instance of a single UoP Input Connection; each endpoint can have only one connection

— UoPOutputEndPoint: each endpoint identifies a single UoP Output Connection; each endpoint can have only one connection

4.3.1          Conformance

The Integration Model is not required as part of the FACE conformance process. It is a descriptive tool to aid integration activities. However, if submitted the CTS will verify the Integration Model for errors against the metamodel and OCL constraints. Should any of these constraints fail, the CTS results will reflect those failures and affect the conformance process. Therefore, the recommendation is to only submit the Integration Model as part of conformance if there are business reasons driving that decision. UoC providers can use the CTS to evaluate an Integration Model to determine a measure of goodness without including the Integration Model in the formal conformance process.

4.4          Traceability Model

The need to provide traceability or references from FACE Data Architecture content to external sources has been identified. This led to the introduction of traceability in the FACE Technical Standard, Edition 3.0. Each TraceableElement can have a reference provided along with a rationale for the trace. The reference is intended to be an unambiguous relation to another document or model (e.g., a standard, specification, or other modelling language element). This provides the recipient of the FACE Data Architecture Model with additional information about its containing context

The types of TraceableElements are: UnitOfPortabiltiy, Connection, AbstractUoP, AbstractConnection, Entity (CDM/LDM/PDM), View (CDM/LDM/PDM), and Query. Each of these elements may have a reference to an external source and rationale provided when the model is constructed.

In addition, the Traceability Model provides the ability to group UnitOfPortability and AbstractUoP elements into a UoPTraceabilitySet. This set can then be traced, as a whole, to one or more external sources.

4.4.1          Conformance

Traceability is not considered as part of the FACE conformance process. It is informational only. However, if submitted the CTS will verify the Traceability Model for errors against the metamodel and OCL constraints. Should any of these constraints fail, the CTS results will reflect those failures and affect the conformance process. Therefore, the recommendation is to only submit the Traceability Model as part of Conformance if there are business reasons driving that decision. UoC providers can use the CTS to evaluate a Traceability Model to determine a measure of goodness without including the Traceability Model in the formal conformance process.

4.5          Model Perspectives

4.5.1          Overview

The model perspective paradigm is a means of looking at a cross-section of the complete data model by focusing on the common modelling tasks at each level in a vertical slicing approach. Model perspectives help the reader to better understand the flow of FACE modelling by grouping elements from different models based on the area of concern. The perspectives are described as:

•         Observation Perspective: describes the leaf data elements which cannot be further decomposed and are used to type Entity and Association Characteristics

•         Entity-Association Perspective: describes data elements that define the meaning and context of application concepts and their relationships

•         Application Perspective: describes the application (or use) of data elements by software components supporting component interface integration

Figure 16 highlights how the perspectives cut across the architecture’s various models and their relationship and usage of the various data models. The red box indicates the focus of the discussion in this section.

		Data Architecture
	Detail:	Context:	Observation Perspective	Entity-Association Perspective	Application Perspective
	Data Model	Conceptual Data Model (CDM)	Observables	Semantics	Query View
		Logical Data Model (LDM)	Measurements Measurement Systems	Refines with Measurements and Constraints	Refines Query View using LDM Entities
		Platform Data Model (PDM)	IDL Data Types	Refines with Types, Multiplicities, and Constraints	Refines the View refining the Query using PDM Entities Defines IDL style Template for DM Type code generation
	UoP Model				PCS, PSSS, Connections (link to Templates)
	Integration Model				TSS data transformation and linkage
	Traceability Model		External Model Traceability	External Model Traceability	External Model Traceability

Figure 16: Data Architecture with Perspectives

The following sections describe each perspective in further detail, identifying the model elements which are grouped in each perspective and how they contribute in the cross-cutting concepts of the perspectives.

4.5.2          Observation Perspective

The Observation Perspective is the vertical slice of the Data Architecture consisting of the lowest-level data items, measurements, and data types used for information exchange. This section focuses on “typed” elements of atomic data referred to as “leaf data items”. The items presented in the section are the conceptual model Observables, logical model Measurements/Measurement Systems, and platform model IDL types.

		Data Architecture
	Detail:	Context:	Observation Perspective	Entity-Association Perspective	Application Perspective
	Data Model	Conceptual Data Model (CDM)	Observables	Semantics	Query View
		Logical Data Model (LDM)	Measurements Measurement Systems	Refines with Measurements and Constraints	Refines Query View using LDM Entities
		Platform Data Model (PDM)	IDL Data Types	Refines with Types, Multiplicities, and Constraints	Refines the View refining the Query using PDM Entities Defines IDL style Template for DM Type code generation
	UoP Model				PCS, PSSS, Connections (link to Templates)
	Integration Model				TSS data transformation and linkage
	Traceability Model		External Model Traceability	External Model Traceability	External Model Traceability

Figure 17: Observation Perspective

The Observation Perspective provides for specifying increased detail at each layer of the model through realization of conceptual Observables to logical Measurements and logical Measurements to platform IDLTypes. Furthermore, when a platform data type realizes a logical Measurement, it must realize all Compositions in the Measurement.

Figure 18 shows the progression from an Observable to a Measurement to an IDLType.

 

Figure 18: Observation Perspective Realization Progression

4.5.2.1         Conceptual Observables

The leaf data item intersecting with both the Observation Perspective and Conceptual Layer is the Observable defined by the FACE Data Architecture. An Observable is something that can be observed but not further characterized, and is typically obtained through measurements of the physical world. An Observable is independent of any specific data representation, units, or reference frame. For example, “distance” may be thought of as an Observable in that it can be measured, but at the conceptual level the nature of the measurement is not specified. The nature of the measurement is specified in the LDM which further defines or “realizes” the Observables by applying specific data such as reference frame. In this context, “realizes” is defined as a method to gradually develop an element by contributing ancillary attributes whose properties further the overall semantic meaning.

Observables are used to describe Conceptual Entities through the definition of their Characteristics. That is, the Observable defines core Characteristics of an Entity and defines the semantic meaning of the most fundamental Entities in your model. When we think in terms of the cross-cutting Observation Perspective we see that the Observable chosen sets the direction for detail discovery at the lower model layers. This is critical to understanding the semantics of the Measurement used to describe the details of the observation. By narrowing the focus to an abstract concept, the modeler can often better see similarities and differences, setting the basic vocabulary of the model in which the data item exists.

4.5.2.2         Logical Measurements and Measurement Systems

The leaf data items intersecting with both the Observation Perspective and Logical Layer are the set of elements to describe Measurements which are defined by the FACE Data Architecture. During the definition of any domain-specific data architecture, the data modeler will find the need to describe data in the form of Measurements. In the FACE Data Architecture all

                   Measurements    are    required    to    be    defined    through    a    MeasurementSystem.    The

MeasurementSystem describes the overall system of measurement for a Measurement. It is the MeasurementSystem that provides an unambiguous description of the measurement’s component axes, the measurement’s orientation (i.e., handedness), and axes relationships through reference to a CoordinateSystem. The MeasurementSystem binds the Measurement to the real world through the use of ReferencePoints and Landmarks.

A Measurement provides the data type and unit. The Measurement also “realizes” an Observable in order to specify the type of observation being measured.

Note: The Measurement elements are not managed by the FACE CCB and therefore these elements provide the modeler with flexibility to override aspects of the underlying MeasurementSystem. However, the Measurement must still adhere to the core definition of the MeasurementSystem.

4.5.2.3         Platform IDLTypes

The leaf data items intersecting with both the Observation Perspective and Platform Layer are the IDLTypes defined by the FACE Data Architecture. The IDLTypes are directly traceable to the logical Measurements, and focus on language binding details for the data items. There are two subtypes of IDLType: Primitive and Struct. The IDLPrimitive aligns with the normative primitive data types for the standard programming languages, and the IDLStruct is a construct for the modeler to build structured data as prescribed by the same standard programming languages.

4.5.3          Entity-Association Perspective

The Entity-Association Perspective is the vertical slice of the entities and relationships in the Conceptual, Logical, and Platform Data Models that describes the semantic definition of the Entities. The focus is on the discovery and semantic specification of Entities, Associations, and their Characteristics refining with additional details with each lower model level.

		Data Architecture
	Detail:	Context:	Observation Perspective	Entity-Association Perspective	Application Perspective
	Data Model	Conceptual Data Model (CDM)	Observables	Semantics	Query View
		Logical Data Model (LDM)	Measurements Measurement Systems	Refines with Measurements and Constraints	Refines Query View using LDM Entities
		Platform Data Model (PDM)	IDL Data Types	Refines with Types, Multiplicities, and Constraints	Refines the View refining the Query using PDM Entities Defines IDL style Template for DM Type code generation
	UoP Model				PCS, PSSS, Connections (link to Templates)
	Integration Model				TSS data transformation and linkage
	Traceability Model		External Model Traceability	External Model Traceability	External Model Traceability

Figure 19: Entity-Association Perspective

The purpose of the Entity-Association Perspective is to build a contextual picture for the models’ domain. The modeler must discover the definition of Entities that sufficiently describes “Things” (Things = ideas, concepts, etc.) and the relationships, be they association, composition, or generalization/specialization between “Things” in a single level. This contextual picture will be repeated at all model levels and linked across layer boundaries through realization relationships.

The realization linkage of Entities and Associations ensures the traceability of the data elements from the lower more specific model levels to the higher more abstract model levels. The traceability of data constructs within a FACE Data Model begins at the conceptual level. The Observable, Entities, and Associations are the top of the realization hierarchy for the individual data values, identifying the high-level abstractions or concepts to which the platform data values are traced, through the logical measurements.

Figure 20 shows an example slice for the Entity-Association Perspective and its intersection of the CDM and LDM. In this example, the Entities and Associations are the same; it’s how the compositional Characteristics are typed at each layer where the refinement becomes evident. The curly brackets on left side of the diagram highlight the Aircraft refinement, showing each of the logical Aircraft’s Compositions as realizing the conceptual Aircraft Compositions.

 

Figure 20: Conceptual to Logical Refinement

It is important to understand that the function of the model layers is to refine the semantic meaning of the elements modeled in the adjacent top layer. The CDM defines the semantics of the Entities and Associations. Lower-level models refine only the Entities attribute/characteristic information. They do not change the semantics or define new information. All logical elements, be they Entities, Associations, or Characteristics are influenced by the high-level decisions defining the Conceptual Layer.

The following sections focus on the refinement aspects of the LDM and introduce realization, the refinement mechanism, and explain how it impacts the logical Entity-Association Perspective with its characterizations.

4.5.3.1         Characteristics

A Characteristic is a feature/property/attribute of an Entity or Association. The Metamodel defines types of Characteristics: compositional and relationship participation. The compositional and relationship Characteristics are composed into an Entity or Association and contribute to its definition. A Characteristic in a compositional role of an Entity or Association does not exist outside of the Entity or Association. Relational Participant Characteristics identify Entities acting in an Association. In this role, participating Characteristics do not contribute to the definition for the Entity, but do contribute to the definition of the Association.

The lineage of the Characteristics for Entities and Associations within a FACE Data Model begins at the conceptual level; the modelling of Conceptual Entities and Associations is the top of the realization hierarchy setting the objects and relationships acting in the domain of the defined FACE Data Model. The Characteristics defined for Conceptual Entities and

Associations prescribe the scope of Characteristics for any logically realized Entity/Association. Each of the Characteristics that are typed using Observables (as opposed to those typed using an Entity) must be considered for whether it needs to be measured and how it will be measured with respect to the Logical Layer. For the novice modeler, discovering the semantics of the data can seem challenging; and even more so because conceptual constraints/recommendations like “single Observable” and “Entity uniqueness” have implications at the logical level, as shown in the following section.

4.5.3.1.1        Same Characteristic Measured Differently

Many times when considering the data, the modeler may find an object in the domain that seems to reflect the same property multiple times. This is a fairly common discovery when considering the system data when analyzing the interfaces. For example, an Interface Control Document (ICD) may define an Aircraft as having ground speed, true speed, or air speed. When considered from the data model perspective and defining a picture of the domain, it is understood that an Aircraft truly only has one speed. However, the single speed property of the Aircraft can be measured in multiple ways (i.e., true, ground, or air).

The FACE Data Model provides support for the concept of multiple measurement types through the ability of multiple Measurement Compositions in an Entity to “realize” a single Observable. Figure 21 shows an example of the Speed Observable composed in the Conceptual Aircraft Entity and how the Logical Aircraft Entity Compositions realize the Observable as GroundSpeedMeasurement named “_speed” and AirSpeedMeasurement named “_speedInAir”.

  

Figure 21: Single Speed Characteristic Measured Differently

Note: The modeler can only add Characteristics when realizing a specific Characteristic from the previous layer. Any added Characteristic must have a realization to the layer above. In Figure 21, it would be incorrect to add a Characteristic to the Logical Entity like aircraft max altitude or aircraft engine horsepower.

4.5.3.2         Realization

The realization concept can be a difficult relationship to understand in the modelling paradigm; however, careful consideration of the following dictionary definitions can help with understanding what realization means to data modeling:

•         An act of becoming fully aware of something as fact

•         The fulfilment or achievement of something desired or anticipated    The result of a process

The term “realization” is used to denote the relationship between entities in the CDM and LDM or between the LDM and the PDM. More specifically, it denotes the relationship between Entities/Associations and Characteristics between model layers. So, a more complete definition we will use in this guidance document is:

“Realization” is the relationship between similar model elements across levels of abstraction.”

When an element realizes another more abstract element, it cannot conflict with the element it realizes. That is, it must adhere to the rules of realization as defined in the Metamodel and OCL constraints.

Examples of the various realizations used in the FACE Data Architecture are shown throughout the sections below.

Pitfall:

Don’t confuse the concept of realization with that of generalization or specialization.

4.5.3.3         Entities and Associations

Entities and Associations are the primary elements in the Entity-Association Perspective. Entities and Association models create the definition of the entities. The CDM describes the semantic definition of all Entities and is refined through the Logical and Platform Entities which provide a more detailed description of Characteristics.

The modelling of CDM Entities and Associations is the top of the realization hierarchy setting the objects and relationships acting in the domain of the defined data model. This layer is the high-level abstraction identifying the semantics or concepts to which the platform manifestation will be traced, through the Logical Layer.

Since the Conceptual Layer is intended to capture the most complete picture with respect to the semantic view of the Domain, this layer can portray a broader sense of the modeled Domain that can be narrowed logically through realization. There are two forms of realization: single realization and down-selection.

4.5.3.3.1        Single Realization

 

Figure 22: Single Realization, Not Specialized

Logical Entities and Associations must be realizations of a respective element in the Conceptual Layer, with the intent to add specific detail to refine the abstract representation. The practice of single realization means, that for any single model domain, each Logical Entity/Association that realizes a Conceptual Entity/Association will be unique in that no other realizing Logical Entity/Association has the same Compositions.

Best Practice:

When modelling the Logical Layer, if an Entity or Association is required to complete the context, having only one LDM Entity or Association realizing the conceptual element reduces model complexity and ensures clarity.

It is appropriate to use multiple logical elements to realize a single conceptual element when different sets of logical choices (as defined by measurement types) apply to logical realization of Entity or Association definitions. An example is the case where all Characteristics are measured with SI units as opposed to US units, as shown in Figure 23.

 

Figure 23: Multiple Realization

4.5.3.3.2        Down-Selection

The Conceptual Layer may capture Entities and Associations that are not realized at the Logical Layer. This happens when Associations are important to show the semantic meaning of Entities but are not directly used by a software component. In this situation, it is not unusual to drop the Entity between the Conceptual and Logical Layers where conceptual meaning does not add value to the logical. This process is known as down-selection. For Entities and Associations, down-selection is the process of leaving out some Entity/Association because that Entity/Association does not further contribute to the desire meaning for the current working model layer.

Figure 24 shows an example of down-selection. The FixedWing Entity provides context to the CDM, but in this situation it is not a contributing element to the scope of the LDM and therefore is not propagated in the logical or platform model levels.

Best Practice:

Use down-selection to realize only those Entities and Associations necessary to capture the logical meaning for the current FACE Data Model.

 

Figure 24: Down-Selection, Fixed Wing Entity

4.5.3.4         Specialization

An Entity can specialize a more abstract, or generalized, Entity. Through specialization, the more detailed (specialized) Entity “inherits” characteristics from the more abstract (generalized) Entity. Each Entity can specialize at most one Entity. Specialization contributes to the uniqueness of an Entity.

Note: The FACE 3.0 Metamodel no longer contains the FACE Technical Standard, Edition 2.1 form of generalization where a generalization metamodel element was created which generalized two or more Entities.

 

Figure 25: Specialized Entities of Aircraft

The specialization relationship ensures the specialized Entity inherits the Characteristics of the super type Entity. This removes the burden from the modeler to explicitly add those Characteristics to the specialized Entity as only the additional distinct Characteristics are modeled.

Note: Specialization in the FACE Data Architecture is not an “is-a” relationship nor does it imply polymorphism. It is simply a convenient means for construction.

4.5.3.5         Association Characteristic Participant Path

This section provides additional detail for describing Associations. Specifically, it describes how to use the path attribute of the Participant meta-class. The path attribute allows the data modeler to specify not only the model element participating in the Association, but additionally the absolute scope, or context, of the model element with respect to the wider data model.

The first part of this section defines the term “context” along with a few general examples, followed by a set of definitions, and examples specific to the FACE Data Architecture.

Note: The use of Participant paths is an advanced topic that may be referred to at a later date as readers become more familiar with modelling Associations.

4.5.3.5.1        Context

The Merriam-Webster's Collegiate Dictionary defines context as “the parts of a discourse that surround a word or passage and can throw light on its meaning”. If we replace “discourse” with “data model” and “word or passage” with “model element (or group of model elements)” we start to define what context of a model element means within the FACE 3.0 Metamodel:

The parts of a data model that surround a model element (or group of model elements) that throw light on its meaning.

                   For       example,       if        our       data       model       has       a       Measurement        called

CircumferenceMeasurementRealFeet that has a Value Type of Real and Units of Feet. If we were to reference this Measurement, without any context (i.e., without other portions of the data model that surround it), then it would just be a circumference measurement.

In order to understand the context of the Measurement, we might ask questions such as: what is this Measurement the circumference of?

When we start to answer the questions of “composed into” or “associated with”, we are providing a context for one model element in terms of another (or set of) model elements. Consider the following answers to the question, each providing a different context for the circumference measurement:

1.          It is the circumference of a piston

2.          It is the circumference of a piston that is in an engine

3.          It is the circumference of a piston that is in an engine of an aircraft

4.          It is the circumference of a piston that is in an engine in a tank

5.          It is the circumference of a piston that is currently undergoing depot maintenance by a field engineer

6.          It is the circumference of a piston that was part of depot maintenance

Figure 26 and Figure 27 show references to the circumference measurement in various contexts. Figure 26 shows an example of no context and examples that reflect answers 1-3 above. Figure

27 shows an example of answers 4-6. Note that the dashed arrow labeled “<<Reference>>” is intended to represent a FACE path, either a FACE 2.1 Characteristic Projection path, FACE 2.1 AssociatedEntity path, or a FACE 3.0 Association Participant path.

 

Figure 26: Context Examples 1 to 3

 

Figure 27: Context Examples 4 to 6

4.5.3.5.2        Participant Paths

The following terms are used to describe Participant paths.

Table 1: Participant Path Descriptions

Term	Meaning
Association (Meta-class)	An Association formalizes the relationship between two or more Participants and may contain one or more Characteristics that describe the relationship.
Participant (Meta-class)	Part of the definition of an Association, a Participant specifies a model element that contributes to the definition of the Association.
Type (Meta-class attribute)	The “type” attribute of Participant references either: •     The Entity or Association that is participating in the Association (if Path is empty) •     The beginning (sometimes called Anchor) for the Path that specifies the destination model element that is participating in the Association
Path (Meta-class attribute)	The “path” attribute of Participant consists of zero or one Path Node elements, the latter of which, when taken together in sequence with other Path Node elements, specify the model element participating in the Association. The Path provides an absolute scope to the participating model element from the Anchor through other elements in the model. The Path provides context of the model element participating in the Association.
Path Node (Meta-class)	Each Path Node captures a portion of a Participant’s Path. A Path Node is specialized as a Characteristic Path Node and Participant Path Node. A Path Node points to zero or one Path Node elements in order to terminate or continue the definition of a Path.
Characteristic Path Node (Meta-class)	Characteristic Path Node references a single Characteristic that contributes to the definition of a Path, used to specify a portion of the Path through a Characteristic Composition or Characteristic Participant.
Participant Path Node (Metaclass)	Participant Path Node references a single Participant that contributes to the definition of a Path, used to specify a portion of the Path backwards from the “type” of a Participant to the Association.
Anchor (informal term)	Informal name for the “type” attribute of the Participant meta-class when the Participant’s path is not empty. The Anchor is the model element at the beginning of a Participant’s Path. Graphically the Anchor is the model element that a Participant “points to”.

Figure 28 and Figure 29 show portions of the FACE 3.0 Metamodel relevant to the defined terms and subsequent discussion.

 

Figure 28: FACE 3.0 Metamodel: Entity, Association, and Participant

 

Figure 29: FACE 3.0 Metamodel: Participant and Path Nodes

4.5.3.5.3        Assumptions

A Participant’s “type” can be an Entity or an Association.

The final Path Node in a Participant’s path must be either a Characteristic Composition (of an Entity or Association) or a Characteristic Participant (an Entity or Association).

If the upperbound cardinality is greater than 1, a Characteristic Path Node must be the final.

4.5.3.5.4        Relevant FACE 2.1 Metamodel

Figure 30 shows a portion of the FACE 2.1 Metamodel relevant to this discussion.

 

Figure 30: FACE 2.1 Metamodel: Association and Associated Entity

4.5.3.5.5        Example Model

Characteristic Path Node Example I

Consider a partial model that shows a single model element participating in an Association. In this example, the model element is the Characteristic Composition “ID” within the context of Entity E1.

For clarity, the example model is shown using both FACE 2.1 and FACE 3.0 nomenclature and a metamodel visualization. Figure 31 and Figure 32 exemplify the FACE 2.1-style solution, whereas Figure 33 and Figure 34 show the FACE 3.0 style.

 

Figure 31: FACE 2.1 Model – Simple Path

One of the Participants in the Association A1 is the “ID” Characteristic Composition of Entity E1. The “type” (or the anchor) for the Associated Entity path is the Entity E1.

 

Figure 32: FACE 2.1 Metamodel Visualization – Simple Path

As with the previous example, one of the Participants in the Association A1 is the “ID” Characteristic Composition of Entity E1. It is not readily apparent from the FACE 3.0 diagram that the “ID” Characteristic is participating in the Association. The Characteristic Path Node must be considered in order to understand this.

 

Figure 33: FACE 3.0 Model – Simple Path

The metamodel for the FACE 3.0 solution for specifying the path is shown below.

 

Figure 34: FACE 3.0 Metamodel Visualization – Simple Path

Note that in both 2.1 and 3.0, the “type” (or anchor) of the Participant path is the Entity E1. In the 2.1-style path specification, the Path string of “.ID” indicates that Characteristic Composition “ID” of Entity E1 is participating in the Association A1. The 3.0 approach indicates the same “ID” Characteristic Composition of the Entity E1 but uses instances of metaclasses: the Participant composes a single Characteristic Path Node that references the Characteristic Composition “ID” of Entity E1.

Characteristic Path Node Example 2

Consider a slightly more complicated example where the context of the single model element participating in Association A1 is modified to include an additional Association A2. As with the previous example, the first two diagrams illustrate the FACE 2.1 solution, and the last two the FACE 3.0 solution.

 

Figure 35: FACE 2.1 Model - Complex Path

In the metamodel visualization, another set of Association and Associated Entity instances are required. Note that the “path” for the Associated Entity from Association A1 now includes the rolename of the Associated Entity from Association A2 to Entity E1.

 

Figure 36: FACE 2.1 Metamodel Visualization - Complex Path

Once again, in the FACE 3.0 diagram, it is not obvious (other than by looking at the rolename of the A1 Participant) which model element is participating in the Association A1.

 

Figure 37: FACE 3.0 Model - Complex Path

The metamodel visualization shows this clearly: the Characteristic Participant “e1_id” of the A1 Association specifies a path by composing a Characteristic Path Node that points to the Characteristic Participant “e1” of Association A2. This Path Node in turn composes another that points to the Characteristic Composition “ID” of Entity E1.

 

Figure 38: FACE 3.0 Metamodel Visualization - Complex Path

Participant Path Node Example 1

The previous sections showed examples of paths where the context is specified “forward” through one or more Associations to the model element that participates in the relationship. The meta-class Participant Path Node is used when the path traverses “backward” from the “type” of the Participant to the Association.

Figure 39 uses the same names for the Associations and Entities as the previous examples, but is quite different. The Association A1 now has a Participant (Associated Entity in the FACE 2.1 Metamodel) that is the ID Characteristic Composition of the A2 Association in the context of Entity E1.

 

Figure 39: FACE 2.1 Model – Backward Traversal through Association The related metamodel visualization for this is shown in Figure 40:

 

Figure 40: FACE 3.0 Metamodel Visualization - Backwards Traversal through Association

Now let’s take a look at the FACE 3.0 model. This model is similar to the 2.1 model, with Associated Entity changed to Participant, and the path removed from the diagram.

 

Figure 41: FACE 3.0 Model - Participant Path Node

In Figure 42, note the use of the meta-class Participant Path Node. It is used to traverse “backward” from the “type” of a Participant to the composing Association.

 

Figure 42: FACE 3.0 Metamodel Visualization - Participant Path Node

Participant Path Specification

As can be seen from the previous examples, FACE 2.1 paths are specified using a string metaattribute of the Associated Entity meta-class, while FACE 3.0 paths are specified in terms of instances of meta-classes in the FACE 3.0 Metamodel (Characteristic Path Node and Participant Path Node).

In this section, we explain Participant paths in further detail and use the 2.1-style string specification on the diagrams for clarity, as shown in Figure 43.

 

Figure 43: FACE 3.0-Style Diagram with 2.1 Path

In Figure 43 a single Participant is shown for both the A1 and A2 Associations. Note that the rolename is shown on the Participant line near the Association, while the path (if present) is shown on the Participant line near the Participant’s “type”. When a path is not shown, as is the case on the Participant line next to the A3 Association, this indicates an empty path.

Example Model

Consider the following model.

 

Figure 44: Example Model for Path Specification

Participant paths “Pf path” and “Pb path” represent to-be-specified paths used in this section to explain path specification. Pf is used to specify paths that are “forward” through the model, meaning that the path is specified with one or more Characteristic Path Nodes, whereas Pb is used to specify paths that are “backward” through the model, meaning that the path is specified with one or more Participant Path Nodes.

Implicit versus Explicit Participant Paths

The FACE Technical Standard, Edition 3.0 requires “explicit” Participant paths. This means that when specifying a path for Pf, and a Participant with a path is encountered (P1 for example), the path for Pf must call out each of the Characteristics explicitly to reach the ID3 Characteristic of Association A3 (see Explicit/Forward (Pf) cell). It cannot, for example, when encountering the path specified for P1, automatically assume P1’s path as part of its path in order to progress forward from A1 directly to A3 (see Implicit/Forward (Pf) cell).

Likewise, when specifying a path for Pb, the path must explicitly include the path “backward” to achieve the ID1 Characteristic of Association A1 (see Explicit/Backward (Pb) cell). It cannot assume, as part of its path, the path of Participant P1 to automatically progress backward from A3 to A1 (see Implicit/Backward (Pb) cell).

Table 2 illustrates this.

Table 2: Explicit versus Implicit Participant Paths

Implicit/Explicit	Forward (Pf Path)	Backward (Pb path)
Implicit (Dis-allowed)	.a2.ID3	->a2[A1].ID1
Explicit	.a2.a3.ID3	->a3[A2]->a2[A1].ID1

Path Honoring

Even though explicit pathing is required, the modeler is encouraged to specify paths that “honor” the semantics of the model in regard to Participant paths.

Using the example model provided in Figure 44, Participant P1 of Association A1 specifies that the model element participating in the Association is the Association A3 within the context of Association A2. This means that the Association A1 is defined by the Participant and that any path that follows P1 should “honor” the path defined by P1.

Forward Path

Consider Table 3 that presents several forward paths for Pf path along with their validity and explanation.

Table 3: Forward Path Examples

Path	Validity	Explanation
.a2.ID2	Invalid	The path does not honor the semantics of the model since Participant P1’s path requires following the a3 rolename of Participant P2.
.a2.a4.ID4	Invalid	The path does not honor the semantics of the model since Participant P1’s path requires following the a3 rolename of Participant P2.
.a2.a3.ID3	Valid	The path honors the semantics of the model since it includes Participant P1’s path.

Backward Path

Table 4 presents several backward paths for Pb path along with their validity and explanation.

Table 4: Backward Path Examples

Path	Validity	Explanation
->a3[A2].a4.ID4	Valid	The path honors the semantics of the model since Participant P2 is between A2 and A3.
->a3[A2].ID2	Valid	The path honors the semantics of the model since Participant P2 is between A2 and A3.
Path	Validity	Explanation
->a3[A2]- >a2[A1].ID1	Valid	The path honors the semantics of the model since the path includes the (backward) path of Participant P1.

This is illustrated in Figure 45.

 

Figure 45: Graphic Representation of Valid Paths

OCL Constraint Issues

The OCL constraints for path validation are not consistent. Currently, the implicit paths are valid for forward paths (Characteristic Path Nodes) and explicit paths are valid for backward paths (Participant Path Nodes).^[1]

4.5.4          Application Perspective

The Application Perspective is the vertical slice that describes the application (or use) of the data model to model software components and component interface integration. The modelling constructs, query and view, select the portions of the data model that are used to develop UoP interfaces: the UoP Model defines the software component, and the Integration Model describes the TSS connections between two more UoPs. The result of this perspective is the definition of UoPs sufficient to support code generation for UoP TSS message interfaces and TSS data transformations.

		Data Architecture
	Detail:	Context:	Observation Perspective	Entity-Association Perspective	Application Perspective
	Data Model	Conceptual Data Model (CDM)	Observables	Semantics	Query View
		Logical Data Model (LDM)	Measurements Measurement Systems	Refines with Measurements and Constraints	Refines Query View using LDM Entities
		Platform Data Model (PDM)	IDL Data Types	Refines with Types, Multiplicities, and Constraints	Refines the View refining the Query using PDM Entities Defines IDL style Template for DM Type code generation
	UoP Model				PCS, PSSS, Connections (link to Templates)
	Integration Model				TSS data transformation and linkage
	Traceability Model		External Model Traceability	External Model Traceability	External Model Traceability

Figure 46: Application Perspective

As we move down the levels of the Data Model for the Application Perspective, we see that the Conceptual Queries are realized by Logical Queries and then Logical Queries are realized by Platform Queries. However, note that while the Conceptual and Logical Queries are defined as Views, Platform Queries are not Views. The platform Template that references Queries as boundQuery and effectiveQuery elements is the actual View at the platform level. The reason for this structure was to maintain the relationship between UoP Connections and Views. Since the Template construct was added in the FACE 3.0 Metamodel to define the structure of the exchanged information, the Template had to be referenced by the UoP Connections.

The realization and construction of Views is described in Section 4.5.4.1.

4.5.4.1         Views

Views are a cross-model concept in the Application Perspective. Views describe the interfaces, or in metamodel terms the connections, for a UoP.

Views are used to describe a subset of data model elements that are to be used in an information exchange. Views focus on only those Entities and Associations between those Entities that are pertinent to the information exchange.

Conceptual and logical Views are created through a query language similar to the Structured Query Language (SQL) Data Query Language (DQL). While it is similar to SQL, note that it is not SQL and is defined within the FACE Technical Standard with a formal grammar, constraints, and a language description.

Pitfall:

The reader may try to think of these data model queries as selecting data from relational database tables. This is inadvisable as the data model queries are not executable, and do not select existing data. The data model queries are used to describe the data set that is desired for the information exchange.

In the PDM, in addition to the Platform Query, the View defines the structure of an information exchange much like programming language structures such as the IDL “struct”. This is done using the Template Language that consists of a formal grammar, constraints, and IDL Language binding. The FACE Technical Standard specifies the formal grammar, the Data Model Language binding specification, and IDL generation from the Language. The Template Language constraints are located in the FACE Shared Data Model Governance Plan.

4.5.4.1.1        Query Language

The Query Language identifies a subset of the data model entities and relationships that are of interest for a query view for the purpose of defining the data that can be transported over an information exchange.

Note: The Conceptual and Logical Queries are optional, but when used must conform to the query grammar definition and query constraints.

In order to better understand the usage of queries we need to first look at the structure of queries described in the following section.

4.5.4.1.2        Query Language Structure

The data model Query Language is very similar to the SQL SELECT statement. A simple example of a query is:

select position, extents from RelevantOperatingPicture

This query selects the characteristics _position and _extents from the Entity named RelevantOperatingPicture. Keywords in the query are highlighted in bold.

The general form of a query can be thought of as several “clauses” in the form of:

SELECT select_clause  FROM from_clause

JOIN join_clauses

WHERE where_clause

ORDER BY order_by_clause

Each of the clauses is described below.

select_clause

The _{select_clause} identifies a list of the characteristics contained in the View. Each characteristic is identified with the Entity or Association that contains it so there is no ambiguity. from_clause

The _{from_clause} identifies the Entity/Association that is the “focus” in the Query. The relationship between the additional Entities is defined with the _{join_clause}. join_clause

The _{join_clause} identifies those Associations or Characteristic Compositions of Entities that are of interest to the query. It provides the link between Entities through Associations that specify that elements, Compositions, and Associations are referencing the same instance.

Note: The _{join_clause} is very different from database SQL as there are no keys in the data model and joins are only valid across Associations.

where_clause

The _{where_clause} further defines the data values that are acceptable to be sent or received over a UoP Connection. This can be thought of as a data filter; however, this information is not used at run-time to filter the actual values on the connection, but rather specifies what data values a UoP will send or receive. order_by_clause

The _{order_by_clause} further defines the data values that are acceptable to be sent or received over a UoP Connection. This can be thought of as a data filter; however, this information is not used at run-time to filter the actual values on the connection, but rather specifies what data values a UoP will send or receive.

                   Note:      The FACE Technical Standard defines the formal EBNF for the Query Language.

4.5.4.1.3        Query Language Syntax

The following syntax provides a summary of the Query Language. The Query Language normative description is described in the FACE Technical Standard.

The notation used is as follows:

•         Bold uppercase words are Query Language keywords; for example, SELECT or WHERE keywords

•         Bold symbols are literal and must be supplied; for example, ( _subquery ) means that a subquery must be surrounded by parenthesis

•         The pipe | symbol means “or”; e.g., ALL | DISTINCT means ALL or DISTINCT

•         Square brackets [] indicate optional data; e.g., [ALL | DISTINCT] means that either the ALL or DISTINCT keywords can be optionally specified

•         _expression indicates a complex definition that is described elsewhere; for example, whereexpression , subquery

•         Parentheses () indicate zero or more elements inside the parenthesis

•         Double slashes // indicate an inline comment to assist the reader

•         /* ……. */ indicate a block comment

•         All other text is literal and unchanged; e.g., the asterisk “*”, the period “.”, the colon “:”, and the equal sign “=”

•         _entity is the name of the Entity in the data model

•         _{characteristiccomposition} is the Composition of an Entity or Association

•         _{characteristic} is the Composition or Participant of an Entity or Association

•         _{enumerationlabel} is an enumerations literal name in the data model

•         _alias is an identifier of the form: [a-zA-Z][_a-zA-Z0-9]*; for example, _MyAlias5, anotheralias

                   Note:      The asterisk means match zero or more of the previous item.

Figure 47: Data Model Query Language Syntax

Note: All keywords like SELECT can only be all uppercase or all lowercase. Mixed-case keywords are not allowed. This is in contrast to the data model elements, such as

Entity and Characteristics, which are not case-sensitive. For example, “_AIRCRAFT” is the same as “Aircraft”.

4.5.4.1.4        Query Language Examples

Figure 48 is a set of simple example queries based on the following model:

 

Figure 48: Dog Ownership Conceptual Model Example

The queries below are provided as a set of simple examples:

// One dog’s name select name from Dog

 

// One Person and each Dog the person owns select Person.*, Dog.* from Person 

join DogOwnership on Dogownership.owner = Person join Dog on DogOwnership.dog = Dog

 

// One Person, each Dog’s name and age, and DogOwnership information 

SELECT Person.*, Dog.name, Dog.age, DogOwnership.*

FROM Person 

JOIN DogOwnership on DogOwnership.owner = Person JOIN Dog on DogOwnership.dog = Dog

The example queries shown above only touch on the descriptive power of the query language.

                   Note:       Notice that the only literal values that can be used in a query are Enumeration literals.

All other comparisons are made relative to other characteristics.

The Query Language is supported at all data model levels: Conceptual, Logical, and Platform. Query Language Constraints differ at each model level, and are described below in more detail.

Conceptual View: Query

Queries in each data model level have somewhat different rules of construction and validation. For example, a Conceptual Query _{where_clause} cannot specify an enumeration limitation like a Logical Query, but instead can only specify constraints in relation to other Entity characteristics. This is due to the level of detail available in the conceptual model versus the logical and platform models.

A Conceptual Query is optional in the data model; however, Conceptual Queries may be used to define information exchanges for an AbstractUoP to define its AbstractConnections.

Logical View: Query

Queries at the logical level define the logical View. Logical Queries can optionally realize a Conceptual Query. Logical Queries can provide more detail about the data set that is defined

(_selected) by the Query. This is due to the level of detail specified by logical characteristics and their typing of Measurements. For instance, Enumeration literals can be used in a where_clause to constrain the data set.

Note: The CTS does not perform any checks for consistency between the Logical Query and a realized Conceptual Query.

A Logical Query is optional because it does not add any significant information to a realizing Platform Query. However, Logical Queries can be used by an AbstractUoP to define its interfaces.

Platform View: Template and Query

Templates, which are exclusive to the PDM, define the platform View. Templates allow the modeler to define a hierarchy of data structures that specifies the format of the data a UoP sends and receives through Connections.

The data set on which the Template operates is defined by the Template’s boundQuery. Because of this relationship, Platform Queries are required for UoP Connection definitions. This is why the platform View can be thought of as being defined by the platform Template and Query combination.

Note: There is no check for consistency between the Platform Query and a realized Logical Query. Nor is there a check for consistency between the Logical Query and a realized Conceptual Query. Therefore, it is up to the modeler to ensure consistency so as to not confuse other persons using their model.

Platform Templates are defined more completely in Section 5.4.2.1.2.

 

5            Data Models – In Depth

5.1          Overview

This chapter focuses on the three model levels that constitute the data model portion of the Data Architecture. The FACE Data Model consists of the Conceptual, Logical, and Platform Data Models (CDM, LDM, and PDM respectively). Each level refines and enhances Entity model elements by providing additional detail to the elements at the level above. All three levels of the data model combine to provide a complete definition of each element. The roles of the models are:

•         Conceptual – defines the semantic definition of all Entities and Associations — Is informational in nature

•         Logical – refines these Entities and Associations by describing the characteristics with detailed frames of reference (called Measurements and Measurement Systems)

— Is informational in nature

— Exception is Enumeration Labels which is source for code generation

•         Platform – establishes the specific platform details with language binding references

— Is informational and functional in nature

— Serves as the source for code generation of the TS Interface, with the exception of the Logical Enumeration labels

The remainder of this chapter examines the modelling tasks from a horizontal level approach, discussing elements and model features specific within each level.

5.1.1          Overarching Conventions

As the following sections break down points for consideration specific to each of the data model levels, there are a few naming conventions that are overarching and therefore outlined before delving into the model levels:

•         Names must be unique within each model (Conceptual, Logical, and Platform)          Name uniqueness for elements is case-insensitive

— Do not use case to differentiate between different elements

•         Names cannot contain spaces

•         Naming conventions are left to the discretion of the modeler

— SDM has identified naming conventions for CCB managed elements

— SDM naming conventions can be as other examples for the modeler

5.2          Conceptual Data Model

This section describes the Conceptual Data Model (CDM) elements in more detail.

5.2.1          Observation Perspective

5.2.1.1         Observables

Observables represent things that can be observed such as the Size, Angle, Count, Position, or Mass of an item. The items are not always physical things and therefore their attributes are not always physical, such as an identifier for a mission or the tail number of an aircraft.

5.2.1.1.1        Naming Observables

Observable names must be unique within the scope of the entire data model and should reflect the type of observation they represent. That said, an Observable name should not describe how we represent or measure the Observable. For example, we wouldn’t name the Position

Observable _{PositionDegrees} or _{PositionWGS84} by appending units to the Observable name. In addition, avoid incorporating an Entity name into the Observable name, such as

“_{RadioFrequency}”. In this case an Entity called Radio should be created and the Frequency Observable should be added as a Characteristic of the Radio Entity. Other invalid types of Observables would be those that are groups of things such as a Pride of lions or a Herd of cows.

5.2.1.1.2        Observables and Descriptions

The description of an Observable is used as a formal definition of the Observable. Therefore, great care should be taken in developing the description. All descriptions should be almost complete sentences less the initial article (e.g., drop the “the”) and should end in a period. An example of a good description is: “Torque: Twisting force that tends to cause rotation.”

The description should not contain references to any units or specific measurements that may be derived from the Observable.

For instance, the following shows a bad description and an improved description of an Observable representing Temperature.

Original Description

How hot or cold an item is where ‘0 degrees Celsius’ represents the temperature at which water freezes.

Improved Description

Average kinetic energy of particles in an Entity (i.e., how hot or cold the item is).

In addition, the description should avoid implying implementation. For example, don’t include implementation details in the textual description, such as “… done using text”. The idea is to allow many Measurement references to each Observable in potentially unforeseeable ways.

Where possible, descriptions should use standard definitions. Examples of useful standards are SI, SAE AS-4UCS-3, and ISO 1151.

5.2.1.1.3        Description Pattern

The Observable description should contain the following information:

•         Description of the Observable phenomena

•         Description of the Observable in relation to other things such as the physical world  Example usage of the Observable

For example: “Address – Unambiguous description of a location (e.g., an IP address).”

•         Observed phenomena: the unique identifier of a location

•         Relation to other things such as the physical world: the address space            Example: an IP address

5.2.1.1.4        What Kind of Things can be Observables

The SDM contains the following types of Observables:

•         Identifiers

— Identifier

•         Information Element

— Kind

— Description

•         Counting

— Count — Resolution

•         Measureable with units

— Position

— Mass

— LuminousIntensity

•         Unclassified

— Size

— Order

— Color

Observables should be discernable/representable. The expectation of use or defined purpose is captured when the Observable becomes a Compositional Characteristic on an Entity or Association.

5.2.2          Entity-Association Perspective

5.2.2.1         Entities

5.2.2.1.1        Criteria for Good Entities

An Entity should be a uniquely identifiable thing or concept. An architectural component is composed of Characteristics important for the described system. The level of detail or how far to decompose an Entity depends on the desired granularity of the semantics of the system. The data itself is determined by the characteristics of the Entity.

For example, if a component needs to communicate data about the position of an aircraft, a good

Conceptual Entity would be an “Aircraft” with a “Position” Observable. It would not make sense to create a “Position” Entity in this case because the property of interest is about an aircraft.

When defining Entities, strive to identify the essential concept to be modeled rather than the role the item plays in the domain. For example, in a model of elements in a university domain, it may be tempting to create separate entities for teacher and student, but this would limit the use of those Entities to specific roles in the model or other models. Instead, a more appropriate Entity would be “person”. That Entity could then fill the role of student, teacher, administrator, coach, etc.

 

Figure 49: Person Entity Example

5.2.2.1.2        Naming Entities

Conceptual Entity names and descriptions help explain the concepts of a given domain and improve model quality. Names should be kept simple enough for a broader audience to quickly understand; contextual information should not be embedded in the name (e.g., the name should be “Engine”, not “InstalledEngine”). Descriptions should be kept simple while still capturing the applicable definition of the Entity.

5.2.2.1.3        Entity Uniqueness

The purpose of the OCL “uniqueness” constraint is to make sure that every Entity that is defined is unique. The two Entity uniqueness differentiators are: 

•         Two Entities are composed of different characteristics

•         Two Entities reference different BasisEntities

The best way to ensure Entity and Association elements are unique is to model the Entity, its characteristics, and its Associations is to develop a conceptual definition of the Entities in a more general and comprehensive way.

Pitfall:

Sometimes attempts to satisfy the “uniqueness” constraint lead to artificially adding Observables to an Entity. This shortcut to Entity modelling is frowned upon. Instead, it is better to fully develop the Entity and Association elements or to reference a BasisEntity that is relative to the elements being modeled. Lastly, the application of the “uniqueness” constraint is optional. However, if this constraint is disabled it may be more difficult for other modelers to leverage the models you create as the definitions of the Entities are likely incomplete and ambiguous. After all, the purpose of developing a semantic data model is to clearly define “what” the data is describing without relying on textual descriptions to define the terms. The application of this constraint is potentially a reflection of quality and does not affect conformance.

5.2.2.2         Associations

5.2.2.2.1        Criteria for Good Associations

An Association is a specialized form of an Entity that is a relationship between two or more Entities. Therefore, the criteria for good Association names follows the same criteria as Entities discussed above.

5.2.2.2.2        Naming Associations

Conceptual Association names are dependent upon what the Association is accomplishing. Some examples of Association names are “Installation”, “Propulsion”, “Proximity”, and “Correlation”.

A math equation or operation almost always is indicative of an Association. Examples are average, error, minimum, and maximum.

A Boolean can often imply an Association. For example, if a message has a “_hasSensor” field, this could imply that there is an installation relationship between a Sensor Entity and some other Entity which uses the sensor.

Commands are common in avionics systems. “Command” can be an Association attached to the Entity that is being commanded. It can be the delta between what the current and commanded value is, with the particular Observable being commanded. The following represents a Command/Control pattern:

•         An Association attached to an Entity with a controllable Observable

•         Current state is in the Entity; the Association is with the requirement

5.2.2.2.3        Association Uniqueness

An Association’s Composition uniqueness is determined not only by its Composition, but also by its participating Entities. In the FACE 2.1 Metamodel, these participating Entities are called “Associated Entities” and in the FACE 3.0 Metamodel, they are called “Participants”.

5.2.2.3         Domains and BasisEntities

5.2.2.3.1        Domains

The Domain model element categorizes a set of BasisEntity model elements. A Domain represents an area of knowledge, or subject matter, specific to practitioners within the Domain. Domain elements contain zero or more BasisEntity elements and provide the definition of the knowledge area to which the BasisEntity elements belong.

The figures at the end of this section exemplify the relationship between Domain and BasisEntity model elements. In Figure 50, the Military Operations Domain contains two BasisEntity elements, Event and Track. In Figure 51, the Shipping Industry Domain is additionally shown with a single BasisEntity, Vessel. Note that each BasisEntity is contained within a Domain, each BasisEntity is referenced by zero, one, or more Conceptual Entities, and that a Conceptual Entity can reference more than one BasisEntity in the same or different Domain. This is illustrated in Figure 51 as the MaritimeTrack’s relationships. Figure 52 shows usage restrictions such as:

•         BasisEntity elements cannot reference other BasisEntity elements

•         Conceptual Entity elements cannot specialize BasisEntity elements

5.2.2.3.2        BasisEntities

A BasisEntity represents a domain concept that establishes a foundation (or basis) that a

Conceptual Entity can reference to contribute to the Entity’s definition and uniqueness. A BasisEntity is defined by its name and description, but has no Characteristics. A BasisEntity can serve as a classification for the Conceptual Entity elements that reference them. No notion of inheritance or hierarchical structure is imposed (or implied) by this feature.

The BasisEntity has two significant use cases. BasisEntity model elements:

•         Allow the modeler to specify that two or more Conceptual Entities are different even though they have the same set of Characteristics

•         Allow the modelling of concepts that don’t need further characterization for a Domain, but can be characterized at a later time

Pitfall:

BasisEntity is a CCB managed element and must be added as a contribution to the SDM using the CCB process. Attention should be taken in submitting BasisEntity elements to the SDM CCB to ensure ample time is allocated for approval or disapproval. The associated figures below illustrate the usage rules for how a BasisEntity contributes meaning to model elements that reference them.

An Entity that references a BasisEntity functions the same as an Entity that does not reference a BasisEntity. In Figure 50, the Surface Track Entity references the BasisEntity Track and still acts as a generalization to the specialized Entities Ground Track and Maritime Track.

An Entity can reference more than one BasisEntity to provide its definition. An Entity’s referenced BasisEntity elements are not required to be in the same Domain and do not denote any hierarchical structure. This allows for flexibility in that any Entity, without regard to its Characteristics or relationships, can have its meaning based in different Domain elements. In Figure 51, the Maritime Track Entity has meaning as a Ship and a Track in the Military Operations Domain and as a Vessel in the Shipping Industry Domain.

A BasisEntity cannot be specialized by an Entity, nor can it have any Characteristics (Composition or Participant). It can only be referenced by an Entity. As such the BasisEntity Ship, shown in Figure 52, is in violation of the FACE Metamodel.

 

Figure 50: Domain and BasisEntity Elements Example 1

 

Figure 51: Domain and BasisEntity Elements Example 2

 

Figure 52: Domain and BasisEntity Elements Example 3

Note: The BasisEntity feature is suitable for addressing the challenges faced when strong adherence to the Entity uniqueness and Single Observable rules is required.

5.2.3          Application Perspective

5.2.3.1         Conceptual Queries

Conceptual Queries define the conceptual-level views. Conceptual Views and Queries are optional, but can be used to describe model subsets.

A conceptual View is “realizable“ by a logical View, and a logical View is “realizable” by a platform View, which is then referenced by a Connection.

The conceptual View _{where_clause} can be used for comparisons between different properties. Since the conceptual model does not have detailed data types like those defined in the logical model Measurements, only property comparisons are permitted.

 

Figure 53: Conceptual View Metamodel

A composite Query is represented in the conceptual metamodel as a CompositeQuery and is a collection of two or more Queries. The “isUnion” attribute specifies whether the composed Queries are intended to be mutually-exclusive or not.

 

Figure 54: CompositeQuery Example

5.3          Logical Data Model

This section describes the Logical Data Model (LDM) elements in more detail. It focuses on the Entity-Association and Observation Perspectives.

5.3.1          Observation Perspective

5.3.1.1         Measurement and Measurement Axis

A Measurement adds additional detail to an Entity’s Characteristic Compositions by providing the data type and unit of the Characteristic. The Measurement also “realizes” an Observable in order to specify the type of observation being measured. This is very important to understanding a Measurement, especially when it contains multiple axes as axes “realize” their own Observables that can be different from the overall Measurement.

The Measurement Axis realization of an Observable is optional. Figure 55 shows an example where the modeler chose to show the Observable realization by the MeasurementAxis for AirspeedMeasurementAxis on the right. In the case where the MeasurementAxis does not explicitly realize an Observable, the Measurement Observable is the default. The left side of Figure 55 shows the visual realization representation when the MeasurementAxis realization is not explicitly drawn. Within a multi-axis Measurement, a MeasurementAxis is required to explicitly realize an Observable when the Observable does not correspond to the Measurement’s realized Observable as shown in Figure 56. Examples of these use cases are shown in the following figures.

 

Figure 55: Measurement Realization with Single Axis

5.3.1.2         Measurement Identification Practice

As noted in earlier sections, the difference between conceptual levels and logical levels is refinement of the conceptual abstractions to logical measurable data by adding more specific detail such as units, data types, and a frame of reference. When creating a Logical EntityAssociation model the modeler must identify how each Entity’s Characteristics are measured.

 

Figure 56: Measurement Realization with Multiple Axis

In this example two MeasurementAxis elements realize the Angle Observable, one realizes the Distance Observable, and the Measurement realizes the Position Observable.

Best Practice:

As the discovery process leads to new detail which suggests limitations to the Measurement Systems, the suggested practice here is to delay the creation of the Measurement System. It is possible to create a new Measurement and Measurement Axis, complete the descriptions for both, and leave the other details incomplete. As the discovery and refinement process unfolds, decisions on Measurements could change and become unnecessary. This approach saves time and eliminates extra work for constructs later deemed not required. No problems are caused by deferring this work. Model checks and OCL will identify the deficient Measurement Systems identifying the elements needed to create a conformant data model.

5.3.1.3         Measurement Attributes

Measurement Attributes are used to describe Measurement data with metadata. For instance, a

Measurement’s validity could be described with a Measurement Attribute. This might be used for a GPS Measurement prior to the acquisition of enough GPS satellites to produce an accurate Position Measurement. In effect, the Measurement Attribute gives the ability to relate additional Characteristic data that is closely aligned to the Measurement.

Figure 57 shows relevant portions of the logical and platform metamodel that capture Measurement attribute metadata.

 

Figure 57: Relevant Logical and Platform Metamodel for Measurement Attributes

5.3.1.3.1        Metamodel Rules

The following sections summarize rules specified in the FACE 3.0 Data Architecture metamodel using identifiers in the form “MM-#”. These identifiers are used later in the document alongside examples.

Logical Metamodel Rules

•         MM-1: A Measurement Attribute references a (single) existing Measurement as its “type”

•         MM-2: A Measurement can compose zero, one, or more Measurement Attributes

•         MM-2a: Composition means that a Measurement Attribute is owned by a single Measurement and is named for its usage within the Measurement using a role name

Platform Metamodel Rules

•         MM-3: An IDL Composition realizes zero or exactly one Measurement Attribute

5.3.1.3.2        OCL Rules

The following sections summarize the rules specified in the FACE 3.0 Data Architecture OCL using identifiers in the form “OCL-#”. These identifiers are used later in the document alongside examples.

•         OCL-1: A Measurement cannot use a MeasurementAttribute that references itself^[2]

•         OCL-2: A Measurement with Measurement Attributes is realized by an IDLStruct^[3]

•         OCL-2-1: Each Measurement Attribute is realized as one IDLComposition of the IDLStruct

•         OCL-2-2: Every MeasurementAttribute of a Measurement must be realized^[4]

•         OCL-3: If an IDLComposition realizes a MeasurementAttribute, then the

IDLComposition’s type is a consistent realization of the MeasurementAttribute’s type

5.3.1.3.3        Examples

The examples below are marked with numbered identifiers that correspond to the list numbers.

Measurement without Measurement Attribute

Figure 58 shows the Speed Measurement as it would appear without a Measurement Attribute:

1.          The Speed Measurement has a single Measurement Axis.

2.          The Speed Measurement, as a single-axis Measurement, is realized as an IDL primitive of type Long.

 

Figure 58: Speed Measurement – No Measurement Attribute

Measurement Using a Measurement Attribute

Once a Measurement Attribute is added to the Speed Measurement, the amount of modelling increases. The Speed Measurement Axis must now be realized at the platform level, and the Speed Measurement must be realized as an IDLStruct. Relate the numbered list items below to those in Figure 59.

1.          The Speed Validity Measurement Attribute references the Validity Measurement to define its semantics (MM-1).

2.          The Speed Measurement composes the Speed Validity Measurement Attribute (MM-2).

3.          Since the Speed Measurement composes a Measurement Attribute, it is realized as an IDLStruct at the platform level (OCL-2).

4.          Each Measurement Attribute of the Speed Measurement is realized as one IDL Composition of the IDLStruct (OCL-2-1). Every Measurement Attribute of the Speed Measurement must be realized (OCL-2-2).

5.          The Validity IDL Composition type (Validity IDL Boolean) is a consistent realization of the Speed Validity’s type (Validity Measurement) (OCL-3).

6.          An IDL Composition realizes zero (0) or exactly one Measurement Attribute (MM-3).

 

Figure 59: Speed Measurement with Single Measurement Attribute

Incorrect Use of Measurement Attribute – Case #1

In the following example, an incorrect use of a Measurement Attribute is shown.

                          #1: A Measurement cannot use a Measurement Attribute that references itself (OCL-1).

 

Figure 60: Incorrect Use of Measurement Attribute Case #1

Incorrect Use of Measurement Attribute – Case #2

In the following example, OCL constraint OCL-3 is violated and is therefore an incorrect usage of the Measurement Attribute. Health IDL Boolean does not realize Validity Measurement (the Measurement that types the Speed Validity Measurement Attribute).

                          #7: If an IDL Composition realizes a Measurement Attribute, then the IDL

Composition’s type is a consistent realization of the Measurement Attribute’s type (OCL-

3)

 

Figure 61: Incorrect Use of Measurement Attribute Case #2

5.3.1.4         Measurement System and Supporting Elements

The Measurement System, with its supporting elements, establishes the foundational references to measure the data items. This underlying system supports the logical detail measurements for each data item. Note that the term “Measurement System” does not necessarily imply the use of numbers or that a physical phenomenon is being measured. For example, an Enumeration can be used to

“measure” a temperature (i.e., HOT, COLD). As another example, a number can be used to “measure” a street.

5.3.1.4.1        What can be an Axis?

The name “axis” is somewhat misleading as many people often equate the term axis with “dimension”. The axis is not a dimension, but rather, simply stated, an axis is a portion of the Measurement System. For example, in a two-dimensional positional Measurement System there would typically be two axes, x and y. That said, the axes can represent just about anything you desire to compose into a measurement. A four-axes Measurement System could be x, y, z, and t. where t is time. That said, we want Measurement Systems to be as reusable as possible while still remaining meaningful. A good indicator is that a MeasurementSystemAxis realizes Observables and therefore is defined by that realization.

5.3.1.4.2        Why is a Measurement System Linked to a Coordinate System, isn’t this Redundant?

The simple truth is yes, it is a little redundant since the numbers of axes must match. That said, the measurement metamodel portion of the logical Measurement System was designed to maximize reuse. Therefore, Coordinate Systems are standalone and define the number of axes, axis relationship description (i.e., orthogonality), plus distance and angular equations. This way, each measurement system can simply point to the Coordinate System without having to restate those attributes.

5.3.1.4.3        What is a Good Reference Point?

Reference points are used to tie the Measurement System to the “real world”. For example, an Earth Centered Earth Fixed (ECEF) MeasurementSystem has (0,0,0) as its origin and specifies the Landmark as the center of the earth. That said, the origin is not sufficiently specified if we do not further tie the ECEF Measurement System to the geoid. If the geoid is not specified, then any measurement could be misunderstood. Therefore, the reference points must be specific and describe one and only one point. Typically, the reference points should be equated to the physical world or to an external standard reference system.

5.3.1.5         Landmarks, Reference Points, Parts, and Default Value Type Units

Reference points, as described above, are used to link the Measurement System to either the real world, or to other published standards, etc. This is accomplished by defining a Landmark; for example, the _{InternationalDateLine} is defined in text as “Describes the position of the

                   InternationalDateLine       at       the       Equator”.       A       reference       point       called

NorthPoleAtPrimeMeridian can then be defined in the ECEF Measurement System at the coordinate (latitude: PI/2, longitude, 0). The Units for the coordinate reference point parts are defined by the DefaultValueTypeUnit on each MeasurementSystem axis as _RealRadians for both latitude and longitude axes.

5.3.1.5.1        When is a New Measurement System Required?

Measurement Systems should be created when an Observable is to be refined into a Measurement and the “topology” of the Measurement is not currently represented by existing Measurement Systems (i.e., the axes don’t match up).

Measurement Systems should be created when they describe a Measurement that is somehow fundamentally different than existing Measurement Systems. Fundamental differences are described as those differences that would allow a single Measurement to be described with more than one point in the Measurement System or rather, if the point cannot be described unambiguously. More simply, if the number of axes is different, or the reference points don’t adequately describe the Landmarks and location of the Landmark for your Measurement, a new Measurement System should be created.

5.3.1.6         Number of Reference Points

The minimum number of reference points required in fully describing a Measurement System is N where N is the number of axes. This assumes that none of the reference points lie on the same axis. The reason that it is not N+1 is because we already describe the axes relationships of the Measurement System through the Coordinate System and the angle and distance functions defining the Measurement System.

5.3.1.7         Standard Measurement System

In the case of data items defined by standards that are accepted as de facto in industry, the FACE Data Architecture provides a mechanism at the Logical Layer for the modeler to simply reference that recognized Technical Standard. The Technical Standard defines this mechanism as follows:

“A StandardMeasurementSystem is used to represent an open, referenced Measurement System without requiring the detailed modelling of the Measurement System. The reference should be a formal or industry standard which defines the full comprehension of the underlying Measurement System.”

The modeler should be aware that for any data items defined as a standardized measurement, the identified standard must meet the following criteria:

•         It is normative by industry or formal authority

•         It is well-defined

•         It can be referenced

•         It can appropriately realize an Observable

An example of a StandardMeasurementSystem is a JPEG image. The JPEG standard is ISO/IEC 10918^[5] and defines an encoding for photographic images.

 

Figure 62: StandardMeasurementSystem Example

The model above shows that the _{JPEGMeasurement} realizes the _Image Observable. Since JPEG is quite complex and is most often treated as a single element and meets the criteria, it makes good sense to define it as a StandardMeasurementSystem.

5.3.1.8         Syntax/Naming

In order to maintain consistency and clarity, the guidance put forth touches on best practices of naming conventions for the Logical data elements defined through Measurements, Measurement Systems, and supporting metamodel elements. Since, some of the elements covered in this section are not subject to CCB management, the best practices listed here are merely recommendations. For those metamodel elements under the CCB management purview, these naming conventions will be enforced for all new elements submitted through the CCB process. The guidance provided in this section will cover syntax specific for each element.

The Measurement and Measurement Axis are not CCB-managed elements so naming conventions are recommendations for best practices from a single UoP perspective. The FACE Technical Standard and the SDM impose these recommendations on all Measurement and Measurement Axis candidates for inclusion in the SDM.

Measurement

This section identifies naming rules for Measurement:

             Suffix every name with _{_ Meas}           In general:

— Measurement System aligned:

— To the degree that the Measurement is explicitly aligned with the

Measurement System, then the recommended _{<Measurement System}

Name (without the suffix)>_<VTU Name>_Meas — Measurement specific:

^— <Measurement Name>_<VTU Name>_Meas

Measurement Axis

This section identifies naming rules for Measurement Axis:

             Suffix every name with _{_ MeasAxis}    In general:

— Measurement System aligned:

— To the degree that the Measurement is explicitly aligned with the

Measurement System, then the recommended _{<Measurement System} Axis Name>_<VTU Name>_ MeasAxis — Measurement specific:

— <Measurement Name>_<VTU Name>_ MeasAxis

The syntax and naming of Measurement Systems and related elements are very specific to help data modelers find applicable Measurements and Measurement Systems. Also, since a Measurement System’s Units are flexible and can be overridden by a Measurement, do not embed units and/or type in the name of Measurement Systems or Measurement System Axis. The following syntax guidance should be used for naming CoordinateSystem, Landmark, ReferencePoint, MeasurementSystem, and MeasurementSystemsAxis elements.

Coordinate System

This section identifies naming rules for Coordinate System:

•         Use common name for Coordinate System (e.g., “Cartesian”)

•         Suffix every name with _{_CoordSys}

•         If there are multiple variants on the Coordinate System, then use the following to differentiate:

— Single-axis system: <Coordinate System Name>_<Axis Name>

— Multi-axis system: <Coordinate System Name>_<Number of Axes>D, or

— <Coordinate System Name>_<Common Multidimension Name>, or

— <Common Multidimension Name>

— Multi-axis system variants (or for clarity on a multi-axis system): <_Coordinate System Name>_<Number of Axes>D_<Axis Names> (e.g., Cartesian_3D_XYZ versus Cartesian_3D_XYT)

•         If a variant is added in a CR, assess the existing CoordinateSystem names and adjust if necessary; for example, “Discrete” exists today – if “Discrete_2D” is added, then

“Discrete” would change to “Discrete_<name of axis>”

Coordinate System Axis

This section identifies naming rules for Coordinate System Axis:

•         Suffix every name with _{_ CoordSysAxis}

•         In general: <Coordinate System Name>_<Axis Name>_CoordSysAxis (where Coordinate System Name is the name of the CoordinateSystem that uses the axis)

— If the supported Coordinate System is a single-axis coordinate system: _<Coordinate System Name>_CoordSysAxis

— If multiple Coordinate Systems use the axis: <Coordinate System Category>_<Axis Name> (e.g., Angular_Azimuth_CoordSysAxis)

•         If an axis of a CoordinateSystem is added that uses an existing CoordinateSystemAxis, assess the existing CoordinateSystemAxis names and adjust if necessary

Measurement System

This section identifies naming rules for Measurement System:

•          Suffix every name with _{_ MeasSys}

•          In general, if there are multiple variants of the Measurement System, then use the following to differentiate:

— Single-axis system: <Measurement System Name>_<Axis Name>

— Multi-axis system: <Measurement System Name>_<Number of Axes>D, or

^— <Measurement System Name>_<common multdimension name>

— Multi-axis system variants (or for clarity on a multi-axis system): _{< Measurement} System Name >_<Number of Axes>D_<Axis Names> (e.g., Cartesian_3D_CoordSys versus Cartesian_4D_CoordSys)

— Frame of reference is a further variant (e.g., _{Course_MagnetNorth})

•          If a variant is added in a CR, assess the existing CoordinateSystem names and adjust if necessary; for example, “Discrete” exists today – if “_{Discrete_2D}” is added, then

“Discrete” would change to “Discrete_<name of axis>”

Measurement System Axis

This section identifies naming rules for Measurement System Axis:

•         Suffix every name with _{_MeasSysAxis}        In general:

— If the supported Measurement System is a single-axis coordinate system:

<Measurement System Name>_MeasSysAxis

— If multiple Measurement Systems use the axis: <Measurement System Name>_<Axis

Name>_MeasSysAxis (where Measurement System Name is the name of the MeasurementSystem that uses the axis)

•         If an axis of a MeasurementSystem is added that uses an existing

MeasurementSystemAxis, assess the existing MeasurementSystemAxis names and adjust if necessary

Unit

This section identifies naming rules for Unit:

•         In general, use the common name for the Unit in plural form (e.g., use _{Watts, Feet,} Meters instead of Watt, Foot, Meter)

•         If the Unit is a rate, use the singular form (e.g., use “_{MetersPerSecond}” instead of

“MeterPerSeconds”)

•         Avoid abbreviations and be mindful that a “common name” might be confused with a different unit

•         Do not add a suffix

Value Type Unit

This section identifies naming rules for the ValueTypeUnit:

•         In general: <_{ValueType Name>_<Unit Name>}

•         If the VTU contains a constraint: <ValueType Name>_<Unit Name>_<Constraint Name_>

Enumeration Value Type Unit

This section identifies naming rules for the Enumeration Value Type Unit:

                          In general:

— Suffix with “_Enum”

Value Type Unit Constraint

This section identifies naming rules for Value Type Unit Constraint:

•         In general, use a concise description of the Constraint (avoiding underscores)

•         For range Constraints where the best description appears to be the range itself:

<LowerBound>_to_<UpperBound_<”Inc” or “Exc”> (e.g., UTC_HourOfDayConstraint)

•         For enumeration Constraints: <Name of VTU (without suffix)>_<Concise Description of Constraint>

Landmarks

This section identifies naming rules for the Landmarks:

•         In general, use a concise description of the Landmark

•         If the Landmark is based on the value at some number of units: _{<Number of Units in}

English (not numeral)><Name of Unit> (use the words “one” or “single” instead of the digit “1”)

•         When possible, avoid using the name of a Measurement that uses the Landmark in the Landmark name

•         When it is truly appropriate to use the name of the Measurement: _{<Name of} Measurement>_<Name of Landmark> (e.g., BodyAngle_Origin)

Reference Points

                          For zero value reference points, use:

Zero<MeasurementSystemAxisName>ReferencePoint (e.g., ZeroMassReferencePoint)  For one value reference points use:

One<UnitName><MeasurementSystemAxisName>ReferencePoint (e.g., OneKilogramMassReferencePoint)

5.3.1.9	Constraints
5.3.1.9.1	Overview

At the logical level of the Observation Perspective, data types are modeled using Measurements.

Measurements are supported by other elements such as MeasurementAxis, MeasurementSystem, MeasurementSystemAxis, and ValueTypeUnit. There are often cases when we want to constrain the Measurement’s set of valid values in order to more accurately describe what is being measured. This is accomplished by placing one or more Constraints on any or all of these elements.

The metamodel provides the MeasurementConstraint element to optionally apply one or more ordered, text-based, descriptive Constraints on the following elements: Measurement, MeasurementAxis, MeasurementSystem, and MeasurementSystemAxis. The Constraint element is used to optionally apply a single Constraint to a ValueTypeUnit. Whereas MeasurementConstraint is limited to a text string, Constraint has several sub-types, each of which has attributes specific to the ValueType being constrained.

When considering the application of a MeasurementConstraint, it is important to understand that the Constraint becomes part of the definition. As such, careful consideration should be used to determine which element is constrained. Incorrect application of Constraints can have unintended impacts to the overall usage and flexibility of the constrained elements.

5.3.1.9.2        Where to Place Measurement Constraints

The MeasurementSystem and its related elements are defined as part of the SDM for the intended purpose of stability, consistency, and reusability. Any Constraints on the MeasurementSystem contribute to its defined, foundational meaning, the implication of which is to constrain not only the MeasurementSystem, but any Measurements that are based upon it, limiting reusability.

The following provide general criteria for MeasurementSystem Constraints:

•         Consider only Constraints that have to be part of the definition of the

MeasurementSystem or its immediately related elements

•         For best chance of reusability, defer the Constraints; apply these to the Measurement, MeasurementAxis, or ValueTypeUnit for the MeasurementAxis

•         If the Constraint doesn't vary from one Measurement to the next, then the Constraint could be a candidate for the MeasurementSystem or immediately related elements

5.3.1.9.3        General Criteria for Measurement Constraints

This general set of criteria is intended to help the modeler select the correct element to apply the Measurement Constraints:

•         For Measurements with multiple MeasurementAxis elements, a Constraint that is applicable to the values on all axes should be applied to the Measurement or MeasurementSystem

For example, the Constraint: “the X and Y axis values must be within the confines of a circle” should be applied to the Measurement or MeasurementSystem because the Constraint pertains to both the X and Y axes.

•         For Measurements with multiple MeasurementAxis elements, if the Constraint is applicable to a single MeasurementAxis, and each MeasurementAxis is independent, then apply the Constraint to the MeasurementAxis

For example, if only one MeasurementAxis must be less than 100 feet, then only one MeasurementAxis should have this Constraint applied.

•         For Measurements with multiple MeasurementAxis elements, if the Constraint is applicable to every MeasurementAxis, and each MeasurementAxis is independent, then the Constraint may be applied to the Measurement, or each MeasurementAxis For example, if each Measurement must be less than 100 feet, and each axis is independent, then the MeasurementConstraint can be applied to the Measurement, or on each MeasurementAxis. 

•         For Measurements with multiple MeasurementAxis elements, if the Constraint is applicable to a single MeasurementAxis, where the axes are dependent, then apply the Constraint to the Measurement

For example, the height can be no more than half the length.

MeasurementConstraints help in naming the element they constrain:

•         If the MeasurementConstraint pertains to a MeasurementAxis, then use the Constraint in the name of the MeasurementAxis

For example, _{MA_HeightRealMetersLE10000} to denote a MeasurementAxis that constrains height to real values that are less than or equal to 10,000 meters.

•         If the Constraint pertains to part of a MeasurementAxis, then use the ValueTypeUnit element’s Constraint in the name of the MeasurementAxis part

For example, _{VTU_HourOfDay0to23}.

•         If a Measurement looks suitable aside from its MeasurementConstraints, then create a different Measurement with a different set of MeasurementConstraints Other considerations:

•         The distinction between absolute and relative Measurements is important when considering creating MeasurementConstraints or using a constrained Measurement For example, if we constrain a latitude Measurement to have values from –90 to 90 degrees of arc, then it would be improper to use this Measurement for a difference in latitude, which could range from 0 to 180 degrees of arc.

5.3.1.9.4        Value Type Unit Constraints

The Constraint element is optionally attributed to ValueTypeUnit to specify the valid range of values for ReferencePoint, ReferencePointPart, MeasurementSystemAxis, and

MeasurementAxis elements. In general, constrain the ValueTypeUnit:

•         When the constraint universally applies, such as when constraining values to non-negative real numbers

•         When a MeasurementAxis has multiple parts

The ValueTypeUnit should be used to constrain the parts; e.g., a MeasurementAxis that consists of three parts: hour, minute, and second, where the hour Constraint is either 0-12 or 0-23

•         When using an EnumerationConstraint

Through the use of the EnumerationConstraint element, the modeler can select a subset of EnumerationLabels that apply to different ValueTypeUnits.

5.3.1.10       Conversions

The metamodel provides elements to support the definition of conversions between two Measurements, MeasurementSystems, or Units. The goal for these conversion elements is to provide additional specification which can be leveraged for code writing and generation.

The conversion elements provide text-based attributes to capture the conversion specification. They do not provide any formal mechanism; however, it does not preclude an organization from specifying the use of a more formal approach; e.g., a conversion library such as MathML.

5.3.1.10.1      Measurement Conversion

The MeasurementConversion element is provided in order to support interoperability between different Measurement definitions. This element specifies the mapping between two Measurements (source and destination) to describe how one measured quantity is transformed into another.

 

Figure 63: MeasurementConversion Metamodel Elements

The conversion is captured as a set of equations in the equation attribute. The specific format of equation is undefined. The loss introduced by the conversion equations is captured in the conversionLossDescription attribute. The specific format of conversionLossDescription is undefined.

The MeasurementConversion element is expected to be used mostly during the integration of multiple application data models whose semantics are similar, but differ in their Measurement realization. Usage within a single application data model, for purposes other than integration, is expected to be minimal.

5.3.1.10.2      Measurement System Conversion

The MeasurementSystemConversion element is provided in order to support interoperability between different MeasurementSystem definitions. This element specifies the mapping between two Measurement Systems (source and target) to describe how one measured quantity is transformed into another. 

 

Figure 64: MeasurementSystemConversion Metamodel Elements

                   Measurement    System    conversions    are    captured     in    the    same    manner    as    the

MeasurementConversion described above. The use of this type of conversion within a single

application data model is expected to be more frequent. The MeasurementSystem element provides the underlying context for measuring quantities, defining reference points, units, and potential Constraints. The expectation is that similar Measurement Systems with minor variations will likely exist in support of a single application data model. For example, a few common Measurement System conversions may be:

•         The unidirectional conversion from a 3D to a 2D position

•         The conversion of Military Grid Reference System (MGRS) position to a position based on the WGS-84 reference frame

The purpose of these conversion elements is to provide additional documentation with respect to the relationships between the identified source and target MeasurementSystems. The FACE Shared Data Model Governance Plan defines the MeasurementSystemConversion element as a Basis Element, meaning that additions of MeasurementSystemConversion elements to the SDM must be approved for inclusion by the SDM CCB.

5.3.1.10.3      Unit Conversion

Unit conversion is achieved through the Conversion element, which describes the conversion between a source and destination ConvertibleElements. Note that the metamodel currently defines a single ConvertibleElement (Unit) and a single Conversion (AffineConversion). The AffineConversion defines a function between the affine spaces which preserves the relational reference of the transformed units.

 

Figure 65: Conversion Metamodel Elements

Note: The MeasurementSystemAxis reference to the ValueTypeUnit element(s) sets the default value type and unit for the MeasurementSystem. When a Measurement’s default ValueTypeUnit is overridden through the specification of a ValueTypeUnit on the Measurement’s MeasurementAxis, an implicit conversion is assumed between the MeasurementSystem and the Measurement. This requires that the implicit conversion between the default ValueTypeUnit and the override ValueTypeUnit be well-defined by a standard; e.g., implicitly converting from real meters to real feet.

The best practice recommendation is to use a Unit conversion in addition to the ValueTypeUnit override applied to the MeasurementAxis in order to avoid the implicit conversion.

5.3.2          Entity-Association Perspective

5.3.2.1         Characteristic Realization

Typically, the characteristics of Logical Entities and Associations are realized as a 1-to-1 correspondence with the characteristics from the conceptual counterpart. In these cases, the modeler simply needs to go through the effort of identifying the logical Measurement aligned with the Observable selected at the conceptual layer. Should the frames of reference or units not align there will be some additional work to capture that detail. Refer to white papers covering topics on Measurements and Measurement Systems for more detail.

The use case where the 1-to-1 correspondence is not true requires some additional effort to identify the full realization mapping between the Conceptual and Logical Entity characteristics. The example below shows this use case. Note the Conceptual Aircraft has three characteristics: ID, duration, and speed. The modeler can easily infer the Logical Entity characteristics and realizations for ID, duration, and speed. However, the name characteristic in the Logical Entity does not initiatively map to a Conceptual Entity characteristic.

To determine the correct mapping relationship for “name” the modeler needs to look at the logical representation of the “name” characteristic defined by the NameMeasurement in the SDM. How is the NameMeasurement related back to a conceptual Observable? For the NameMeasurement that relationship is directed to the Identifier Observable. Therefore, both the logical ID and the name characteristics have a relationship mapping back to the conceptual ID characteristic.

 

Figure 66: Rolename Change in Realization

Best Practice:

Many tools will default the realization attribute as long as there is continuity between characteristic rolenames across the layers. It is recommended to maintain the rolenames across all layers. Should the rolename change the realization must be explicitly modeled.

5.3.2.2         Down-Selection

In the Conceptual Layer there may be additional characteristics captured that are not reflected directly in the information exchanged by the UoP. In this instance it not unusual to find that some characteristics will not propagate through the lower layers. Therefore, it is not unusual to drop characteristics from Entities/Associations at the Logical Layer. This process is known as Characteristic down-selection and while it is most commonly used for the _Identifier characteristic, the technique can be employed for any characteristic of an Entity/Association. The interpretation is the preceding layer should be a superset of all the necessary characteristics to define completeness at that layer and may or may not have meaning at lower layers.

 

Figure 67: Characteristic Down-Selection

Figure 67 demonstrates the down-selection of two characteristics from the Conceptual Entity. In this example, the LDM only requires the Airport type at the logical level. Therefore, the Gate characteristic has been eliminated as well as the common _Identifier required at the Conceptual Layer.

5.3.3          Application Perspective

5.3.3.1         Logical Queries

Logical Queries are very similar to Conceptual Queries except they operate on the Logical Entity model. In addition, Logical Queries can realize Conceptual Queries and can utilize a Where clause to further specify the allowable data set.

 

Figure 68: Logical View Metamodel

Figure 68 shows where Logical Query, CompositeQuery, and QueryComposition can realize the Conceptual Query elements.

A composite Query is represented in the conceptual metamodel as a CompositeQuery and is a collection of two or more Queries. The “isUnion” attribute specifies whether the composed Queries are intended to be mutually-exclusive or not.

 

Figure 69: Composite Query Example

5.4          Platform Data Model

This section describes the platform metamodel elements and how they are used to develop a Platform Data Model (PDM). The elements described are:

•         Observation Perspective:

— IDL types

— Logical element realization

•         Application Perspective Platform Views:

— Query elements

— Template View

— Composite View

— Template boundQuery and effectiveQuery

5.4.1          Observation Perspective

5.4.1.1         IDLType

A platform IDLType, in the platform model, is used to realize logical Measurements, MeasurementAxis, and ValueTypeUnits.

Only “leaf” metamodel elements of the IDLType (i.e., those that are not further specialized) can be used to realize a Measurement, MeasurementAxis, or ValueTypeUnit. The reader is encouraged to identify these in the FACE Technical Standard §J.2.5 (Meta-Package: face.datamodel.platform). Some of these leaf elements include: IDLStruct, IDLSequence and IDLArray, Boolean, Char, Octet, Float, Double, Long, Enumeration, CharArray, and String. A portion of the related metamodel is shown in Figure 70.

 

Figure 70: IDLType Metamodel

When selecting which IDLType used to represent data, the user should consider the type of data represented, the size, and the range of values, the PDM to IDL bindings, and the IDL to programming language mappings, each of which is specified in the FACE Technical Standard.

5.4.1.2         Realization of Logical Elements to IDLType

Table 5, derived from the metamodel and OCL constraints, lists the set of important points regarding realizations of logical elements into IDLTypes.

Table 5: Realization from Logical Elements to IDLType

ID	Description
1	IDLType realizes AbstractMeasurement, which is a generalization of Measurement, MeasurementAxis, and ValueTypeUnit.
2	IDLType is a generalization. Only “leaf” types of IDLType can be used for platform realization.
3	The IDLType leaf that is selected determines the size, range of values, and the implementation type in the chosen language.
4	IDLSequence and IDLArray can only realize Measurements whose Measurement System is of type StandardMeasurementSystem.
5	A ValueTypeUnit is realized as an IDLPrimitive.
6	A Measurement that has a single MeasurementAxis with one ValueTypeUnit and no MeasurementAttributes is realized as an IDLPrimitive.
7	A Measurement that has a single MeasurementAxis with multiple ValueTypeUnits and no MeasurementAttributes, is realized as an IDLStruct with one IDLComposition per ValueTypeUnit.
8	A Measurement with multiple MeasurementAxis elements is realized as an IDLStruct with one IDLComposition per MeasurementAxis.
9	A MeasurementAxis that has a single ValueTypeUnit is realized by an IDLPrimitive.
10	A MeasurementAxis that has multiple ValueTypeUnits is realized by an IDLStruct, where each ValueTypeUnit of the MeasurementAxis is realized as a unique IDLComposition of the IDLStruct.
11	A Measurement that has MeasurementAttributes is realized as an IDLStruct with one IDLComposition per MeasurementAttribute.
12	The platform realization of a logical element is consistent with its logical representation in terms of composition hierarchy and type.

5.4.1.2.1        IDLType Realizes AbstractMeasurement

IDLType realizes AbstractMeasurement, which is a generalization of Measurement, MeasurementAxis, and ValueTypeUnit.

Figure 71 shows an example of each of the logical AbstractMeasurement subtypes realized at the platform level.

 

Figure 71: Example of IDLType Realization of AbstractMeasurement

5.4.1.2.2        IDLType is a Generalization

IDLType is a generalization. Only “leaf” types of IDLType can be used for platform realization.

Figure 72 shows each of the leaf IDL types. NAME, used in the figure, is a placeholder for the actual name of the leaf IDL types

 

Figure 72: Leaf IDLTypes

5.4.1.2.3        The IDLType Leaf Selected

The IDLType leaf that is selected determines the size, range of values, and the implementation type in the chosen language.

For example, Table 12 (IDL Basic Type C Mapping) in the FACE Technical Standard illustrates that an IDLType of short has a C Type of FACE_short, a size of 2 bytes, a range of values from –2^15 to (2^15 – 1) and a default value of 0.

 

Figure 73: Portion of Table 12 from the FACE Technical Standard

5.4.1.2.4        IDLSequence and IDLArray

IDLSequence and IDLArray can only realize Measurements whose MeasurementSystem is of type StandardMeasurementSystem.

For example, in Figure 74, because the _{JPEGMeasurement} is based on a StandardMeasurementSystem, it can be realized as an IDLArray at the platform level, whereas the Description Measurement cannot.

 

Figure 74: Platform Realization as IDLArray and IDLSequence from StandardMeasurementSystem

5.4.1.2.5        ValueTypeUnit Realization

A ValueTypeUnit is realized as an IDLPrimitive.

Aside from the special case of a Measurement with a single MeasurementAxis, single ValueTypeUnit, and no MeasurementAttributes, a ValueTypeUnit is always realized as an IDLPrimitive. The example below shows the realization of several ValueTypeUnits of a hypothetical distance measurement that consists of miles, yards, and feet into the IDLPrimitives UShort, UShort, and Octet respectively.

 

Figure 75: Realization of ValueTypeUnits as IDLPrimitives

5.4.1.2.6        Measurement Special Case 1 Realization

A Measurement that has a single MeasurementAxis with one ValueTypeUnit and no MeasurementAttributes is realized as an IDLPrimitive.

For example, in Figure 76, AirspeedMeasurement has a single-axis AirspeedMeasurementAxis with a ValueTypeUnit of _RealKnots, and has no MeasurementAttributes.

 

Figure 76: Realization of Measurement, Single Axis and VTU, no MeasurementAttribute

5.4.1.2.7        Measurement Special Case 2 Realization

A Measurement that has a single MeasurementAxis with multiple ValueTypeUnits and no MeasurementAttributes, is realized as an IDLStruct with one IDLComposition per ValueTypeUnit.

This realization is shown in Figure 77.

 

Figure 77: Realization of Measurement, Single Axis, Multiple VTUs, no MeasurementAttributes

5.4.1.2.8        Measurement with Multiple MeasurementAxis Elements

A Measurement with multiple MeasurementAxis elements is realized as an IDLStruct with one IDLComposition per MeasurementAxis.

 

Figure 78: Realization of Measurement with Multiple MeasurementAxis Elements

5.4.1.2.9        MeasurementAxis with Single ValueTypeUnit Realization

A MeasurementAxis that has a single ValueTypeUnit is realized by an IDLPrimitive.

For example, each of the two MeasurementAxis elements below has a single ValueTypeUnit; MeasurementAxis LongitudeMeasurementAxis has a single ValueTypeUnit (RealRadians) as does MeasurementAxis AltitudeMeasurementAxis (RealMeters).

 

Figure 79: Realization of MeasurementAxis with Single VTU

5.4.1.2.10      Realization of MeasurementAxis with Multiple ValueTypeUnits

A MeasurementAxis that has multiple ValueTypeUnits is realized by an IDLStruct, where each ValueTypeUnit of the MeasurementAxis is realized as a unique IDLComposition of the IDLStruct.

The example below is for a model that is distinct from the special case noted in Item 7 in Table 5.

 

Figure 80: Realization of MeasurementAxis with Multiple VTUs

5.4.1.2.11      Realization of Measurement with MeasurementAttribute

A Measurement that has MeasurementAttributes is realized as an IDLStruct with one IDLComposition per MeasurementAttribute.

For contrast, Figure 81 shows the _{SpeedMeasurement} without MeasurementAttribute.

 

Figure 81: Realization of Measurement without MeasurementAttribute

While Figure 82 shows the changes required in order to support a _{SpeedValidity} MeasurementAttribute.

 

Figure 82: Realization of Measurement with MeasurementAttribute

Section 5.3.1.3 elaborates on MeasurementAttributes in greater detail.

5.4.1.2.12      Realization Consistency

The platform realization of a logical element is consistent with its logical representation in terms of composition hierarchy and type.

Because IDLTypes are used to realize measurements and related logical elements, there is no concept of down-selection – the Measurement and its realization are treated as a whole. This means that the number of elements at the logical level must be equal to the number of elements at the platform level, each element must be realized, and that each of the elements must be equal in type across the realization.

An example of consistency in number of elements and complete realization is: for a Measurement with three MeasurementAxis elements, the IDLStruct that realizes the Measurement must contain three IDLCompositions and each of these must realize one MeasurementAxis. The models in Figure 83 violate this.

 

Figure 83: Violation of Realization – Number of Elements and Complete Realization

Consistency in type across realization means, for example, that the selected platform type of an IDLComposition of an IDLStruct that realizes a Measurement with three MeasurementAxis elements must itself be a realization of one of the MeasurementAxis elements.

Using the example above, when selecting a platform type for the “long” IDLComposition of the PositionStruct IDLStruct, only platform realizations of LongitudeMeasurementAxis should be used. A model that violates this is shown in Figure 84.

 

Figure 84: Violation of Realization: Type Consistency across Realization

5.4.2          Application Perspective

5.4.2.1         Platform Views: Queries and Templates

Platform Views are defined by Templates which format the data defined in a Platform Query. The Platform Query is very similar to the Logical Query except that it operates on the PDM elements. Platform Queries can realize the Logical Query elements much like the logical can realize the conceptual. Platform Templates are defined with an IDL-like Template Language that was developed to allow for the definition of the platform View structure. The Templatebased definition of platform Views differs in this way from conceptual and logical Views in that they allow the modeler to define a hierarchy of data structures that can then be used in the UoP Model through UoP Connections. Platform Queries and Templates are further described below.

The platform View-relevant metamodel is shown in Figure 85.

 

Figure 85: Platform View Metamodel

5.4.2.1.1        Query

In the PDM, a Query is not a View. Instead, the PDM uses a Template to specify the structure of the data for the View. In other words, in the PDM, a Template, and a Query define the View, whereas in the LDM and CDM, only a Query defines the View.

The analog of CompositeQuery is provided in the PDM. CompositeTemplate allows the union of two or more Views through a TemplateComposition.

5.4.2.1.2        Template

Templates define the structure of platform Views. In this way, the Template-based definition of platform Views differs from their conceptual and logical counterparts. Templates allow the modeler to define a hierarchy of data structures that specifies the format of the data a UoP sends and receives through Connections.

A portion of the ROP PDM, described in detail in Chapter 6, is used below to illustrate Platform Queries and Templates.

 

Figure 86: Portion of the ROP Platform Data Model

5.4.2.1.3        Platform Query, Template, and Result Example 1

A very simple Query, Template, and IDL result example is shown below. Although both queries and templates are likely to be captured as text strings, they are shown below using symbology similar to that for other model elements.

Query

In reference to the data model shown in Figure 86, the Query shows the projection of two

Characteristics, _position and _extents, from a subset of the model, the _Area Entity. The “as” keyword creates an alias that can be used subsequently in the Query or in a Template that is bound to it (only for projected characteristic aliases). The Characteristic “extents” of Entity Area is aliased as _size and a reference to Entity Area is aliased as _aoi.

Note: The names of the Entities in the _{from_clause} are guaranteed to be unique since they reference model Entity names which are already guaranteed to be unique. Projected Characteristic names in the _{select_clause} must be unique to the Entities in the from_clause. If the Characteristic name exists in more than one Entity in the from_clause the dot notation must be used to remove the Characteristic name conflict: _Entity.name. For example, the above Query could be written as: _select Area.position, Area.extents as size from Area.

Template

The Template named “Area” contains a single Template method called “main”. The “main” Template method references two projected Characteristics in the Query, position and extents by its alias size.

IDL Result

The resultant IDL for Template “_{AreaOfInterest}” is shown above. Note that the type of the Characteristic is automatically defined because it is known through the Platform Entity model.

Note that the name of the IDLStruct “_{AreaOfInterest}” comes from the name of the Template.

The resultant IDL shown above is an estimate of what would be generated from the Area_OfInterest Template. It is not the responsibility of the modeler to hand-write this code.

5.4.2.1.4        Platform Query, Template, and Result Example 2

A portion of the PDM from the ADS-B example is shown in Figure 87. The _Airport Entity composes _id, _name, _code, and one or more _gates. Note that the _Gate Entity is composed by Airport once, although it is shown using two representations in the figure.

 

Figure 87: Portion of the ADS-B Platform Data Model

Query

In the Query shown above, the select projects four (4) Characteristics, two from the _Airport

Entity (_id and _code) and two from the _Gate Entity (_id and _capacity). Each of the projected Characteristics is scoped using a reference (_airport and _gates) as there can be ambiguity when the names of Characteristic Compositions of Entities are the same; e.g., both _Airport and _Gate have a Characteristic Composition named _id.

The selection begins at Entity _Airport (as specified in the “from” clause), and adds Entity _Gate across the composition with rolename “gates”. The result is a subset of the model sufficient to project the desired Characteristics.

Template and IDL Result

<<Template>> AirportGateData   GateType (Gate) {     Gate.id;     Gate.capacity; } main (Airport) {     Airport.id;     Airport.code;     GateType(Gate) gates; }
	struct GateType {     UniqueIDType id;     CapacityType capacity; } struct AirportGateData {     UniqueIDType id;     AirportCodeType code;     Sequence<GateType> gates; }

The Template above reflects one way in which the projected Characteristics can be packaged along with the matching generated IDL to the right. In this case, the Template was written to affect the structure shown on the right: a structure that contains the identifier and code of the airport and a sequence of gates, each with an identifier and capacity.

Note that the multiplicity of the Characteristic Compositions in the model, the Query, and the reference passed into the Template method all determine what the resultant code looks like.

Table 6 illustrates this in three columns. The first shows the portion of the Template that is being demonstrated, the second the part of the Query that is relevant; the third what the resultant IDL code looks like. A detailed explanation of the Template Language and Template to IDL mappings is beyond the scope of this example.

Table 6: Example Mapping of Template, Query, and Resultant IDL

Template Part(s)	Associated Query Part(s)	Resulting IDL
main (Airport) { }	“from Airport” Note that reference Airport provides the context for the main Template method’s members.	The main Template method is turned into an IDL struct that takes the name of the Template, which in this case is AirportGateData:     struct AirportGateData {     }
Airport.id;	“select Airport.id”	This Template method member is a projected Characteristic reference to Airport.id. It is turned into a member of the AirportGateData IDL structure that carries the name used in the select statement (id) and the type of the Characteristic in the model (UniqueIDType):     UniqueIDType id;
Airport.code;	“select Airport.code”	This Template method member is a projected Characteristic reference to airport.code. It is turned into a member of the AirportGateData IDL structure that carries the name used in the select statement (code) and the type of the Characteristic in the model (AirportCodeType):     AirportCodeType code;
Template Part(s)	Associated Query Part(s)	Resulting IDL
GateType(gate) gates;	“join Gate as Gate on Airport.Gates” Note that reference gate provides the context passed to the GateType Template method.	This Template method member is a Template method reference to the GateType Template method that uses the argument gate from the Query as context. It produces code that is a member of the AirportGateData IDL structure that carries the name gates and is of type GateType (the name of the referenced Template method). The multiplicity of the gates member comes from the multiplicity of the reference gate in the context of the reference Airport. In the context of Airport, gate has a multiplicity of 1..*, and therefore the gates member is generated as a sequence of GateType:     Sequence<GateType> gates;
GateType(gate) { }	“select Gate.id, Gate.capacity” “join Gate on Airport.gates”	The GateType Template method is turned into an IDL structure:     struct GateType {     }
gate.id;	“select gate.id”	This Template method member is a projected Characteristic reference to gate.id. It is turned into a member of the GateType IDL structure that carries the name used in the select statement (id) and the type of the Characteristic in the model (UniqueIDType):     UniqueIDType id;
gate.capacity;	“select gate.capacity”	This Template method member is a projected Characteristic reference to Gate.capacity. It is turned into a member of the GateType IDL structure that carries the name used in the select statement (capacity) and the type of the Characteristic in the model (CapacityType):     CapacityType capacity;

5.4.2.1.5        Composite View

A Composite View is represented in the platform metamodel as a CompositeTemplate, which is a collection of two or more Templates. The isUnion attribute specifies whether the composed

Templates are translated to IDL as cases in an IDL union or as members of an IDL structure.

Note that in terms of the metamodel, there is a level of indirection through TemplateComposition and that the View meta-class (at the platform level) specializes Template and CompositeTemplate to allow structure nesting.

 

Figure 88: CompositeTemplate Example

5.4.2.1.6        Other Platform View Features

Template: Bound and Effective Query

A Template can have an EffectiveQuery and/or a BoundQuery reference. Each Template is a specification that defines a structure for Characteristics projected by its BoundQuery or its EffectiveQuery. As explained above, Queries can be defined in the CDMs and LDMs but must be defined in the PDMs. It is only in the PDM that they are identified as Effective or Bound; their specific meaning and how they are utilized will be discussed below.

A BoundQuery is a Query that a Template is directly “tied to” or “bound to” in order to produce the desired or intended data needed to develop the platform Template data structures.

An EffectiveQuery is a Query that can produce the desired or intended data needed to develop the platform Template data structures. Effective Queries note that a Template is utilizing other Templates and the resulting Query may be a complex combination of bound Queries.

The BoundQuery will always be the Query directly associated with the Template. The EffectiveQuery acts more as a notational device or reference for the modeler and is considered to be optional to the data model. The BoundQuery is not optional to the data model.

Template Annotations

Template annotations are added to a Template method member to affect how the IDL will be generated. There are currently two Template annotations defined:

•         @inline

•         @optional

These are described below.

@inline

The _@inline annotation is used to specify that a template method structure is “in lined” into the containing Template. The following rules apply to the use of the _@inline annotation:

•         Applies to the Template method reference immediately following the annotation

•         May not be applied to a projected Characteristic reference

•         The members of the referenced Template method replace the annotated Template method member in the enclosing Template method’s realized IDL struct

•         The multiplicity of the relationship of the referenced Template method’s Entity type parameter relative to the enclosing Template method’s Entity type parameter must be 1      A member name is not required for the annotated Template method reference

@optional

The _@optional annotation is used to specify that an annotated member may not have a value in a message based on the Template and is therefore “optional”. The following rules apply to the use of the _@optional annotation:

•         Use the _{“@optional”} annotation preceding the Template method member

•         May not be applied to a wild-card projected Characteristic

•         May not be applied to an _@inline annotated Template method reference

•         The annotated member will render as a sequence of length one in your code

main<x> Equivalent Entity Template

The Equivalent Entity Template provides a mechanism to parameterize a Template with different Platform Entity types. This construct allows for greater reuse by requiring that only the Template methods must match. This is in contrast to normal Template method parameters that are statically typed and are therefore tied to only one Entity. An example of the normal Template form is shown in Figure 89.

 

Figure 89 Normal Template Example

This type of Template can be very repetitive on large models that have the same repeating patterns for Characteristics. The Equivalent Entity Template reduces this duplication through the use of a parameter. Figure 90 is an example of the definition and use of the Equivalent Entity Template that optimizes the above example.

 

Figure 90: Equivalent Entity Template Example

Figure 90 shows the Equivalent Entity Template “_{main <x>}” name _{ResourceEquivalent} and is identifiable by use of the angle brackets. To use _{ResourceEquivalent} in another Template we simply pass in a parameter of “p” to identify the Entity type to be used for the IDL generation.

The following are the rules of the use of Equivalent Entity Template methods:

•         The parameter represents an Entity whose suitability is not determined by its type, but instead by the presence of specific Compositions

•         One or more (comma-separated) parameters are flanked by right and left angle brackets (< and >, respectively)

•         In the example above, x represents any Entity that contains Compositions named id and description

•         Similar to “duck typing”, which can work the same as polymorphism, but also without inheritance (and all the baggage that comes with it)

•         Realized as an IDLstruct

•         One or more members, each being a reference to a projected Characteristic in the caller’s BoundQuery

•         The elements referenced by its members are realized as IDL members of the enclosing Template method’s realized IDLstruct

•         Each member must have a unique name in the enclosing Template

•         Scoping can be applied by using one of the two Equivalent Entity Template method types:

— A “main” Equivalent Entity Template method

— A supporting Equivalent Entity Template method

•         A language binding Template whose “main” Template method is an Equivalent Entity Template method may not have:

— Other Template elements (no unions or Template methods of any kind)

— A “Using” statement

— A bound or effective query

•         A language binding Template whose “main” Template method is a static Entity Template method may have zero or more supporting Equivalent Entity Template methods

•         Each Characteristic reference must be Entity qualified: the parameter followed by “.” followed by the role name of a Characteristic; e.g., x.id

•         Characteristic wildcards are not allowed

6            Example Data Models

This chapter walks through the example data models used in this document. The example demonstrates the concept of a Relevant Operating Picture (ROP).

6.1          Relevant Operating Picture Example

The following example is derived from concepts present in the mission systems domain, with the primary focus on what is commonly called the Relevant Operating Picture (ROP). The ROP is defined as the tactical items of interest within a geographic area associated with a specific mission. Tactical items of interest are such things as tanks, trucks, ships, personnel, etc. These represent things that can be tracked by on-board and off-board sensors, and in some cases they can be tracked by both, which can lead to multiple “tracking” relationships that need to be correlated to avoid presenting the crew with an inaccurate view of the tactical situation or ROP.

During execution of a mission, it is important to understand the affiliation of items within the ROP so that the crew has good situational awareness of blue (friendly) and red (threat) forces, as well as those that are neutral or unknown.

The following sections examine pieces of the context described above and present a set of Entities and Associations that comprise the concepts necessary to understand the ROP.

6.1.1          Modeled Domain Concepts

6.1.1.1         Mission-Relevant Area

The above text states that the ROP is defined as a geographic area relevant to a mission. Parsing that simple statement results in the following CDM fragment:

 

Figure 91: Mission-Relevant Area Conceptual Data Model

All of the Entities in this model include an _Identifier property as required by the OCL constraints in the FACE Technical Standard. While this is required at the conceptual level, the Identifier property can be dropped at subsequent levels if it is not required by the application.

The Area Entity is further defined by its location (position) and its size (extents), both of which are Observables defined in the FACE SDM. For this example, there is no need to further characterize the Mission Entity.

Recall that the ROP is defined as “an area relevant to a mission”. The MissionRelevantArea Association provides the link between a mission and a geographic area. The multiplicities on the Association should be interpreted as follows:

•         For any _{MissionRelevantArea}, there is always exactly one Area and one Mission; this is indicated by the respective Participant multiplicities labeled “1..1” nearest to the Area and Mission Conceptual Entities in Figure 91

•         Given any Area, it can be a part of zero or more _{MissionRelevantAreas}

•         Given a Mission, it is always part of exactly one _{MissionRelevantArea}

6.1.1.2         Mission Execution

Missions are executed by _Forces and _Forces are made up of _Platforms (aircraft, ground vehicles, stationary ground installations, ships, etc.). Figure 92 illustrates the set of Entities and

Associations. This diagram tells us that each _{MissionExecution} Association has one _Mission Participant and one Platform Participant, but a _Mission may participate in zero or more

MissionExecutions while a Platform can only participate in one. Stated another way, a M_ission can be executed by multiple Platforms, but a Platform can only execute one _Mission (at a time). A similar pattern is shown for the _{PlatformForce} Association.

 

Figure 92: Mission Execution and Platform Force Conceptual Data Model

6.1.1.3         Armed Force Affiliation

When executing a mission, understanding which items in the ROP are part of the friendly and threat forces is critical. The determination of whether an item is friendly or otherwise is frequently determined by the country with which the force is associated and the current state of relations with that country. Figure 93 shows how these relationships could be modeled.

 

Figure 93: Armed Force Affiliation Conceptual Data Model

A _Country Entity has been added and is characterized by the _Identifier property. To accommodate describing the diplomatic relationships between countries, a _{DiplomaticRelation}

Association has been added to associate one country with another. An _{OperationalState} Observable has been added to the Association to capture the state of the relationship (e.g., friends, enemies, etc.).

Finally, the _Allegiance Association establishes a relationship between some _ArmedForce and a

Country. As shown in the diagram, an _ArmedForce is associated with only one _Country while a Country may be associated with more than one Force (e.g., the USA has multiple forces, but each is affiliated with only the USA).

6.1.1.4         Tracking

One of the primary types of content in the ROP is objects that are being tracked by sensors that are installed in platforms executing the mission. Some correlation algorithms rely on knowing where an item has been as a clue to its behavior and possible intent. To accommodate this, the model includes Entities and Associations to express the history of where an item has been.

Figure 94 illustrates the Entities and Associations that embody the concepts described here.

 

Figure 94: Tracking Conceptual Data Model

6.1.2          Entities and Associations

6.1.2.1         Allegiance

Allegiance is an Association which shows the relationship between an _ArmedForce and a

Country. When used in conjunction with the _{DiplomaticRelations} Association, the idea could be expressed that a force may have allegiance to a country which has hostile relations with our country (i.e., a red force), or is an ally of ours (i.e., a blue force).

6.1.2.2         Area

The _Area Entity represents the idea of a geographic area. It contains Observable properties for position (to say where it is), and extents (to say how big it is). This Entity captures a very simple reusable idea and therefore can be used in any situation that might require reference to a geographic area.

6.1.2.3         Correlation

Correlation is an Association that relates objects that are being tracked. It indicates that there is some perceived correlation between the two items being tracked. This example model shows that this relationship requires one _Object and one or more _{ObjectTrackings}. A unique aspect demonstrated here is the ability to use Associations as Participants in other Associations. This is allowed because Associations are themselves specializations of Entities and add the idea of Participants.

6.1.2.4         Country

Country is an Entity intended to represent a state actor in the world. This example has been kept simple and does not address the idea of non-state actors.

6.1.2.5         DiplomaticRelations

This is an Association that captures the idea of the relationship between different countries. This

Association includes composition of an _{OperationalState} Observable intended to capture the state of that relationship (e.g., friendly, hostile, neutral, etc.).

6.1.2.6         ArmedForce

The _ArmedForce Entity represents a Participant in a military scenario. Armed Forces represent the “sides” such as friendly forces, threat forces, etc.

6.1.2.7         Mission

The _Mission Entity represents the concept of a mission.

6.1.2.8         Mission Execution

The _{MissionExecution} Association captures the relationship between a _Platform and a Mission. This relationship has Participants of one mission and zero or more platforms.

6.1.2.9         Mission-Relevant Area

MissionRelevantArea is the essential Association that brings meaning to the relationship between a mission and a geographic area and forms a key component in the idea of an ROP. This relationship allows consideration of the ROP as the set of Objects whose positions are within the _{MissionRelevantArea}. Taking this further, we can look through the Force, Allegiance, and _{DiplomaticRelations} for those objects to find objects that are red forces or blue forces.

6.1.2.10       Object

The _Object Entity represents some item that may be of interest during a mission. It is intentionally left abstract rather than giving it a more specific label (e.g., track) to allow this

Entity to be used in a broad range of modelling scenarios. Some readers might have expected that “Track” would be an Entity specializing an object. In the ROP example, since the object is shown as participating in an _{ObjectTracking} relationship with the role of track, readers of the model gain understanding that the _Object is a “Track”. “Track” in this example is defined as an object being tracked by a _Sensor.

6.1.2.11       ObjectTracking

ObjectTracking is an Association that indicates a tracking relationship between a sensor and some object essentially making that object a track in this context.

6.1.2.12       Platform

Platform is a generalization of systems that can host a sensor. _Platform has been kept general in order to be used in cases where it represents an aircraft, a ship, a ground vehicle, a ground installation, etc.

6.1.2.13       PlatformForce

PlatformForce is an Association between a Platform and an ArmedForce. 6.1.2.14 PositionAtTime

PositionAtTime is an Entity that represents a position at a specific point in time.

6.1.2.15       Sensor

Sensor represents some piece of equipment that can be used in sensing. In this scenario, little additional characterization is added.

6.1.2.16       SensorPlatformInstallation

SensorPlatformInstalla_tion is an Association that introduces the concept of a sensor being installed in a platform. As the diagram indicates, this relationship requires one sensor and one platform. Platforms can be part of multiple _{SensorPlatformInstallation} relationships (i.e., platforms can have multiple installed sensors), while a sensor can only be installed in a single platform.

6.1.2.17       TrackHistory

TrackHistory is an Association between zero or more _{ObjectTrackings} and zero or more PositionAtTimes.

A            Data Model Glossary

This Glossary includes only terms of elements that can be constructed. Terms in italics are data model elements and use the metamodel model definition. This Glossary does not duplicate the metamodel definitions; for those you should refer to the FACE Technical Standard. Terms with no italics are conversational and describe the concepts: (e.g., ConceptualDataModel versus Conceptual Data Model). Each term includes a description of the ESSENCE of the term and the USE of the term in the metamodel. Terms that are utilized from the FACE AV-2 definitions are marked with (AV-2) next to their name.

Note: The FACE Data Architecture is a new modelling language and therefore does not use other modelling language definitions. Instead, all definitions are contained within the metamodel definition, descriptions, OCL constraints, and the definitions outlined below.

Term	Definition
Architecture Model	The top-level or root container that contains Data Models, UoP Models, Integration Models, and Traceability Models.
Association	Defines the relationship between two or more participants. Each Participant in an Association is described by a typed Entity and its path (see Participant and PathNode). In the FACE Metamodel, the Association specializes an Entity. As such, Associations must follow all the same rules as an Entity. For example, at the conceptual level, its composition characteristic set must include the Identifier Observable. Each Association must have at least one Characteristic.
Basis Elements	Those foundational Data Model elements that are controlled by the FACE SDM CCB.
Basis Entity	A CCB-managed element that represents a unique domain concept and establishes a foundation from which Conceptual Entities can be referenced. Used to differentiate two or more Entities that are different even though they have the same Characteristics. Also allows for modelling of Entities that don’t need to be fully described for a UoP. Note: A BasisEntity cannot contain any Characteristics and is defined only by its description.
Cardinality	The number of elements in a particular set or other grouping. For Characteristic Compositions and Participants, it is the minimum or maximum number of elements making up the Multiplicity.

 

Term	Definition
Characteristic	Either a compositional attribute for an Entity or for an Association, or a Participant Entity which contributes to the defined relationship.
Conceptual Association	An Association within the Conceptual Data Model. (See Association and Conceptual Data Model)
Conceptual Data Model	The semantic definition of Entities and relationships that sufficiently describes “Things” (Things = ideas, concepts, etc.) and the relationships between “Things”. The CDM can also contain Views as well as Entities, Associations, and Observables.
Conceptual Entity	An Entity within the Conceptual Data Model. (See Entity, Association, and Conceptual Data Model)
Coordinate System	Defines the distance and angle equation of the Measurement System. It is reusable and can be referenced by multiple Measurement Systems to define the space. The Coordinate System is comprised of multiple CoordinateSystemAxis. The Coordinate System Axis does not have to be orthogonal and it is not required that the axes be ordered.
Coordinate System Axis	Rrepresents a dimension within a Coordinate System where a dimension is not necessarily geospatial, and the axis is not necessarily continuous. The Coordinate System Axis does not have to be orthogonal, and it is not required that the axes be ordered.
Data Architecture (AV-2)	A set of related models, specifications, and governance policies with the primary purpose of providing an interoperable means of data exchange.
Data Model (AV-2)	An abstraction that describes real-world elements, their properties, and their relationships in order to establish a common understanding for communication between components.
Data Model Language (AV-2)	A language specified as an EMOF metamodel and OCL constraints used to capture data element syntax and semantics.
Defining Property	A defining property contributes to the uniqueness of an Entity or Association. For example, Characteristics are defining properties of both Entities and Associations.
Domain	A representation of a data space defined by a set of BasisEntity elements relating to an area of knowledge specific to practitioners within the domain.
Domain-Specific Data Model (AV-2)	A data model designed to the FACE Data Architecture requirements. It captures domain-specific semantics.

 

Term	Definition
Entity	Represents a Thing or Concept defined by its set of Characteristics, specializations, and BasisEntity references. (See Conceptual Entity, Logical Entity, and Platform Entity)
Entity Equivalence	When two or more Entities have the exact same Characteristics, specializations, and BasisEntity references.
Entity Uniqueness	When all Conceptual Entities in a data model meet the uniqueness constraints (different Characteristics, specializations, and BasisEntity references). Note: Participation in an Association is not used for uniqueness determination.
Frame of Reference	Defined through the Coordinate System, Measurement System, and Reference Points.
Generalization	The formulation of general concepts from specific instances by abstracting common properties.
Logical Data Model	Defines Measurement-related information and uses it to refine the Observable Characteristics of Conceptual Entities.
Logical Entity	An Entity within the Logical Data Model and a means to capture a set of Measurement-related choices for the Conceptual Entity it realizes. (See Entity, Association, and Logical Data Model)
Measurement	Describes a datum’s data type, unit, and the frame of reference as a realization of an Observable.
Measurement System	Provides a detailed frame of reference for Measurements. In addition, it is a system of measure specified in terms of a Coordinate System and a set of axes, reference points, units, and value types.
Multiplicity	The range of the number of elements possible within a set. Each lower bound and upper bound is referred to as cardinality, whereas the range is the Multiplicity. (See Characteristic Compositions and Association Participants)
Observable	Something that can be perceived but not further characterized and is typically quantified through Measurements of the physical world. An Observable is independent of any specific data representation, units, or reference frame. For example, “length” may be thought of as an Observable in that it can be measured, but at the conceptual level the nature of the Measurement is deferred to the logical level.
Object Constraint Language	The language used to define the additional rules of the FACE Data Model.
Participant	An Entity (and path) that takes part in an association/relationship.

 

Term	Definition
Path	A means by which the relational context of a Participant can be narrowed to a specific Characteristic. Note: FACE 3.x only has Association Participant paths.
Platform Data Model	Defines the language IDL type information and uses it to refine the Measurement Characteristics on the Logical Entities.
Platform Entity	An Entity within the Platform Data Model. A means to capture a set of language-related choices for the Logical Entity it realizes. (See Entity, Association, Realize, and Platform Data Model)
Query	The specification for the portion of the Entity model that “matters” to a View.
Realize (Realization)	The relationship between similar model elements across levels of abstraction.
Refinement	The clarification of model elements from a more abstract characterization to a more concrete characterization over the extent of the model levels: Conceptual, Logical, and Platform.
Semantic Definition	The meaning of the data in the information exchange defined solely by the Conceptual Data Model Entities and Associations. Note: Realization of these conceptual model elements or their use in queries does not change the meaning established by the Entities and Associations at the conceptual level.
Shared Data Model (AV-2)	An instance of a Data Model whose purpose is to define commonly used items and to serve as a basis for all other data models. Alignment with the required elements in the Shared Data Model (SDM) is necessary for conformance of any other Data Model. The Shared Data Model is governed by a CCB.
Shared Data Model Configuration Control Board (CCB) (AV-2)	The entity responsible for managing and approving changes to the Shared Data Model.
Specialization	The “specializes” relationship of an Entity is a mechanism to specify that one Entity (the “specializing Entity”) has all the Characteristics of another. Note: Specialization is not an “is-a” relationship, nor does it imply polymorphism. It is simply a convenient means for construction.
Standard Measurement System	Used to represent an open, referenced Measurement System without requiring the detailed modelling of the Measurement System. The reference should be a formal or industry standard which defines the full comprehension of the underlying Measurement System.
Source Multiplicity	Defines the minimum cardinality and the maximum cardinality for the Association relative to the Participant.

 

Term	Definition
Source Lower Bound	Defines the minimum cardinality for the multiplicity of the Association relative to the Participant.
Source Upper Bound	Defines the maximum cardinality for the multiplicity of the Association relative to the Participant. Note: A sourceUpperBound multiplicity of –1 represents an unbounded or infinite quantity.
Template	Specifies the structured grouping of Entity Characteristics, which were identified through a Query that can be converted to IDL 4.1 constructs.
Template Language	A language that is used to specify the structured grouping of Entity Characteristics that can be converted to IDL 4.1 constructs. Note: The Template Language was designed to be like IDL but reduce the overall workload in generating IDL constructs.

 

B           Frequently Asked Questions (FAQs)

This section provides frequently asked questions and answers in response to inquiries on techniques, rules, constraints, and metamodel requirements that may be of importance to the FACE Data Architecture consumer.

Why did the FACE Consortium create a new data model language when there is ____ (UML^®, SysML, OWL, RDF, etc.) that already accomplish the same goals?

The FACE Data Architecture does not specifically follow many of the more traditional approaches in use today although it builds upon the concepts of message modelling, software modelling (e.g., UML), and ontology modelling languages (e.g., OWL, RDF).

The FACE Data Architecture is not a traditional message-based data model. Instead, it defines the foundation necessary for capturing semantic and syntactic data model information.

Why are there three Entity-Association models?

These three levels of model allow for the progression of the definition of data to maximize the reuse of the entities by many UoPs. Modelling activities focus first on developing data concepts, then on the elaboration on those ideas with additional detail until the UoP interfaces have been sufficiently defined.

Why is the Measurement System so complex? Can’t we just use a text description to describe our “Frame of Reference”?

This was, in fact, the original approach that the FACE Consortium took when defining the FACE Technical Standard, Edition 2.0. We soon realized, while developing the criteria for the Frame of Reference description, that it was difficult to define and manage free-text descriptions. So, we developed a model for the frame of reference that allowed all measurements to be described in a consistent way. The result is the Measurement System first introduced in the FACE Technical Standard, Edition 2.1.

How do I use the Count Observable?

The _Count Observable is somewhat different than other Observables in that it describes a set of things. Therefore, it should be composed in an Association or Entity that describes a set of things. To use the _Count Observable, you should compose it into a Conceptual Association or Entity when a tally of the number of items in a set is required. For example, in the figure below, the count composition of Installed Rotor Set is typed to the Observable Count. It corresponds to the actual number of Rotors in the Installed Rotor Set.

 

I know what my message is supposed to look like. How do I create a model to make it look like what I need?

The FACE Technical Standard allows a separation from the Entity-Association Perspective models and the Application Perspective models. The Template Language, in the Application Perspective, allows the creation of message structures called a Template. That said, it does not allow you to define the BIT-level formats (the FACE Data Architecture describes the data not the transport format, which is left up to the TSS implementation).

Assuming adequate Entity-Association models already exist, creating a structure very close to an existing message can be relatively straightforward.

What’s the difference between Area, Count, Extent, Distance, and Size Observables?

Sometimes it is difficult to determine which Observable to use when typing the compositions at the Conceptual level. This is particularly true when deciding between several similar Observables such as Area, Count, Extent, Distance, and Size. In general, use these guidelines:

•         Use the Area Observable to describe the amount of surface space in two dimensions; for example, an Area composition of Airport indicates the amount of surface area taken up by the Airport

•         Use the Count Observable to describe a number (or tally) of items in a set; for example, earlier we showed how the _Count Observable could be used to count the number of installed Rotors on a Rotorcraft

•         Use the Extent Observable to describe the bounding region encompassing an item in one or more dimensions

Extent is used when describing, for example, length, width, or height (or combinations of these) of an item. For example, the extent of a helicopter is the bounding region encompassed by it – the box defined by the length, width, and height that encompasses the helicopter.

 

•         Use the Distance Observable to describe the amount of separation between two points (or positions)

Note that length is different than distance; length is an extent in one dimension or axis.

•         Use the Size Observable only to describe a generic amount or magnitude as a last resort when the composition cannot be typed using other Observables

What does “context” mean?

Context can mean many things:

•         As applied to data Entities and Associations, context is defined in Section 2.2.1.1.1

•         As applied to data Views, context is defined in Section 2.2.1.1.2

•         As applied to Traceability Model, context is defined in Section 2.2.1.4

•         As applied to DSDM, context is defined in Section 2.2.3.2

•         As applied to Domains, context is defined in Section 5.2.2.3.1

•         As applied to Measurement System conversion, context is defined in Section 5.3.1.10.2

•         As applied to Association Participant paths, context is defined in Section 4.5.3.5 and

7.2.2.2

What does it mean to specify a path through a CharacteristicPathNode or ParticipantPathNode that has an upper bound greater than 1?

This is currently undefined and will cause an OCL constraint violation.

What are source upper and lower bound?

The Participant meta-class meta-attributes sourceLowerBound and sourceUpperBound are used to describe Participant multiplicity from the perspective of the Participant with respect to the Association.

 

C            Acronyms

The following acronyms are used within this Guide:

Acronym	Definition
API	Application Programming Interface
BIT	Built-In Test
CC	Common Criteria
CCA	Clinger-Cohen Act
CCB	Configuration Control Board
CCD	Component Configurability Definition
CDM	Conceptual Data Model
CNSS	Committee of National Security Systems
CR	Change Request
CTS	Conformance Test Suite
CVM	Conformance Verification Matrix
DO	Document
DoDAF	Department of Defense Architecture Framework
DoDI	Department of Defense Instruction
DQL	Data Query Language
DSDM	Domain-Specific Data Model
EBNF	Extended Backus-Naur
ECEF	Earth Centered Earth Fixed
EIA	Electronic Industries Alliance
EMOF	Essential Meta-Object Facility
FACE	Future Airborne Capability Environment
FISMA	Federal Information Security Management Act

 

Acronym	Definition
GPS	Global Positioning System
IA	Information Assurance
ICD	Interface Control Document
ID	Identification, Identifier
IDL	Interface Definition Language
IEEE	Institute of Electrical and Electronics Engineers
IETF	Internet Engineering Task Force
IOSS	Input/Output Services Segment
ISO/IEC	International Organization for Standardization/International Electrotechnical Commission
IT	Information Technology
LDM	Logical Data Model
MDA	Model-Driven Architecture
MGRS	Military Grid Reference System
MIL-STD	Military Standard
MOF	Meta-Object Facility
NSA	National Security Agency
NSTISSP	National Security Telecommunications and Information Systems Security Policy
OCL	Object Constraint Languag
OMG	Object Management Group
OSS	Operating System Segment
OWL	Web Ontology Language
PCS	Portable Components Segment
PDM	Platform Data Model
POSIX	Portable Operating System Interface
PR/CR	Problem Report/Change Request
Acronym	Definition
PSSS	Platform-Specific Services Segment
RDF	Resource Description Framework
RFC	Request for Comments
ROP	Relevant Operating Picture
RTCA	Radio Technical Commission for Aeronautics
RTOS	Real-Time Operating System
SAE	Society of Automotive Engineers
SDM	Shared Data Model
SQL	Structured Query Language
SSE	Systems Security Engineering
TS	Transport Service
TSS	Transport Services Segment
UAV	Unmanned Aerial Vehicle
UCS	Unmanned Control System
UML	Unified Modelling Language
UoC	Unit of Conformance
UoP	Unit of Portability
USM	UoP Supplied Model
VTU	Value Type Unit
XMI	XML Metadata Interchange
XML	eXtensible Markup Language